From nobody Sat Jan 3 10:56:09 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 11E7E1A0149 for ; Sat, 3 Jan 2015 10:56:08 -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 T-u4tyGgvMOS for ; Sat, 3 Jan 2015 10:56:06 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB131A0130 for ; Sat, 3 Jan 2015 10:56:06 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so25330735wgh.8 for ; Sat, 03 Jan 2015 10:56:05 -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=ex+O/pZo7b5zeuG1vL5aGf41DIAO0Lw+bZx30pmuXCU=; b=bGw91LQXJdCqUGg4vRKIzUI5Vu/EcaCMFKzEMooEXslCcezakOw2S28WnMKxaJXkFm WJci9sY+MH29JM53n0GAqQYDVGEhuaozG+Ddb4KhDcgwKrhzlHHSdNTM1iPiJjTFmuPI u92oL9qH9WtYyYIg7M8p8fRjw/XTo4xMQksE9HZi/qmzfmOaULI8QU2GI5+KN9SJqtLI LYisujzK4oLTPUZ4OAmWDZhCrqTXcXVu9QHb8mDCVfocSrtf28GjWJ6oK8i5oaymbWn3 tp96Pcb0S/5XhdubNhs4A4nnsd63WplkhcO9kBEWzUhkUafeNMmVnNkEbY9VYTBq6Kd8 E9SQ== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr162609382wjz.89.1420311365177; Sat, 03 Jan 2015 10:56:05 -0800 (PST) Received: by 10.27.204.198 with HTTP; Sat, 3 Jan 2015 10:56:05 -0800 (PST) Date: Sat, 3 Jan 2015 10:56:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=089e0102e4986459cb050bc402c1 Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4xeX4ubtPiZ_X0fq2gx4DZtyR68 Subject: [Dbound] Charter redux 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, 03 Jan 2015 18:56:08 -0000 --089e0102e4986459cb050bc402c1 Content-Type: text/plain; charset=UTF-8 Hi all, I worked with Barry a bit on this over the holidays. A revised version is now available at the same URL: https://github.com/mskucherawy/docs/blob/master/charter-dbound Comments? -MSK --089e0102e4986459cb050bc402c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I worked with Barry a bit on this= over the holidays.=C2=A0 A revised version is now available at the same UR= L:

https://github.com/mskucherawy/docs/blob/master/charter-dbound

Comments?

-MSK
--089e0102e4986459cb050bc402c1-- From nobody Sat Jan 3 17:55:02 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 5F1021A1ACA for ; Sat, 3 Jan 2015 17:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 X27BaHkLN291 for ; Sat, 3 Jan 2015 17:54:59 -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 F3FA31A1AC6 for ; Sat, 3 Jan 2015 17:54:58 -0800 (PST) Received: (qmail 53948 invoked from network); 4 Jan 2015 01:54:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jan 2015 01:54:57 -0000 Date: 4 Jan 2015 01:54:35 -0000 Message-ID: <20150104015435.20842.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: http://mailarchive.ietf.org/arch/msg/dbound/k_Hh4V5NZWfSN-1i4GxjN_vxblo Cc: superuser@gmail.com Subject: Re: [Dbound] Charter redux 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, 04 Jan 2015 01:55:01 -0000 In article you write: >I worked with Barry a bit on this over the holidays. A revised version is >now available at the same URL: > >https://github.com/mskucherawy/docs/blob/master/charter-dbound > >Comments? Basically, it's fine. On line 41-42, it says "different solutions are needed for the email, web, and equivalence problems, and possibly also for other problems in this space" but it hasn't said what the email or web problems are. I would suggest "different solutions are needed for the various problems in this space." R's, John From nobody Sat Jan 3 22:46:09 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 B14DC1A6FE9 for ; Sat, 3 Jan 2015 22:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 O_79CYHw7yPh for ; Sat, 3 Jan 2015 22:46:03 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 428201A6FE6 for ; Sat, 3 Jan 2015 22:46:02 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 014A832E4A1; Sun, 4 Jan 2015 15:45:15 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3eb3_28c3_4bacd84c_faac_42db_bc3d_28d5f4993698; Sun, 04 Jan 2015 15:45:15 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3E8CEBF8EE; Sun, 4 Jan 2015 15:45:15 +0900 (JST) Message-ID: <54A8E17B.5040707@it.aoyama.ac.jp> Date: Sun, 04 Jan 2015 15:45:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Levine , dbound@ietf.org References: <20150104015435.20842.qmail@ary.lan> In-Reply-To: <20150104015435.20842.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/34TEuCeHL-bXIhtDVlS7UJ6lwtw Cc: superuser@gmail.com Subject: Re: [Dbound] Charter redux 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, 04 Jan 2015 06:46:06 -0000 On 2015/01/04 10:54, John Levine wrote: > In article you write: >> I worked with Barry a bit on this over the holidays. A revised version is >> now available at the same URL: >> >> https://github.com/mskucherawy/docs/blob/master/charter-dbound >> >> Comments? > > Basically, it's fine. On line 41-42, it says "different solutions are > needed for the email, web, and equivalence problems, and possibly also > for other problems in this space" but it hasn't said what the email or > web problems are. This shouldn't needed. It could well be that the structure of the problem is the same for web and email, but that the boundaries are different (e.g. because your hosting provider fully takes care of your email to foo.example.com, but you're on your own for the website at foo.example.com). Thanks for creating the Additional Background Information section, it's probably the best way in this case to keep both lengtheners (e.g. Dave Crocker) and shorteners (like me) happy. Small nits: - There is 'email' and 'mail'. Please streamline. - "and such rechartering may only be considered after completion of the base work." gets me confused because the word "may" has too much specific semantics in an IETF context. Otherwise, I'm fine with the current proposal. Regards, Martin. > I would suggest "different solutions are needed for the various > problems in this space." > > R's, > John > > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > From nobody Sat Jan 3 22:55:11 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 13D801A6FEE for ; Sat, 3 Jan 2015 22:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 QHMEdUU4csr9 for ; Sat, 3 Jan 2015 22:55:09 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D65DD1A6FEA for ; Sat, 3 Jan 2015 22:55:08 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 1978532E527; Sun, 4 Jan 2015 15:54:24 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3eb3_29da_3601aa3e_128a_4ec3_8f2a_3931b14c1f5a; Sun, 04 Jan 2015 15:54:23 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 638FDBF8EE; Sun, 4 Jan 2015 15:54:23 +0900 (JST) Message-ID: <54A8E39F.4040006@it.aoyama.ac.jp> Date: Sun, 04 Jan 2015 15:54:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Levine , dbound@ietf.org References: <20150104015435.20842.qmail@ary.lan> <54A8E17B.5040707@it.aoyama.ac.jp> In-Reply-To: <54A8E17B.5040707@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/gemQ8b5EDgpmKfA806uoVVTgEWE Cc: superuser@gmail.com Subject: Re: [Dbound] Charter redux 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, 04 Jan 2015 06:55:10 -0000 Sorry to correct myself: On 2015/01/04 15:45, "Martin J. D=C3=BCrst" wrote: > Otherwise, I'm fine with the current proposal. One important issue: The document at=20 https://github.com/equalsJeffH/dbound should be submitted as an ID (and=20 cited as such) before the charter is finalized. Regards, Martin. From nobody Sun Jan 4 07:04:11 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 0583D1A1AA3 for ; Sun, 4 Jan 2015 07:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] 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 ZUXzpRTAJaBE for ; Sun, 4 Jan 2015 07:04:08 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592861A1A98 for ; Sun, 4 Jan 2015 07:04:08 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t04F42XV027708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Jan 2015 07:04:06 -0800 Message-ID: <54A95658.7080002@dcrocker.net> Date: Sun, 04 Jan 2015 07:03:52 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dbound@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 04 Jan 2015 07:04:06 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/q4l6BlUxwu3DywE4jXtvkHnGYGQ Subject: Re: [Dbound] Charter redux X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 15:04:10 -0000 > https://github.com/mskucherawy/docs/blob/master/charter-dbound FROM: > However, the working > group may discover that different solutions are needed for the email, > web, and equivalence problems, and possibly also for other problems in > this space. TO: However, the working group may discover that different solutions are needed to solve different usage requirements. Citing different applications presumes that apps are what might determine the lines of demarcation between solutions. From what I've seen, apps are merely correlate, where the real distinctions are underlying semantics of "related" and/or different policies associated with "related". Given that the working isn't starting with a single specification that has strong support, let's not have the charter build in a potentially distracting assumption. Besides that, the text I'm suggesting is shorter... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jan 4 21:10:45 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 60F9D1A1B00 for ; Sun, 4 Jan 2015 21:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2BM7Bx0ZTKVu for ; Sun, 4 Jan 2015 21:10:40 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589521A1A7F for ; Sun, 4 Jan 2015 21:10:40 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so7231876wes.40 for ; Sun, 04 Jan 2015 21:10:39 -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=LzJl5K90dZm6qHpx39zUWxOY2CLntXE+AtC9uB1U/g4=; b=EPrYReNGErIXze2AYFlXCcGx38Pa9aidd2YZjIu/e3TUjz5oqetSAXcXOqKbd9GgmO rM4+Wg/IGnVzEa/TtmZQboaDS5Jg8sM7riYAdEiT2XP4fZ7G3lBpE4b/vULb76eVDqLM WhIeFbtoTPGZ4ucapJaefwZ8Cgo8XkXVHgmq7+mYe9UjojWePV7EGJyh3AOOv6k7ddCE pz1wd+gdf2skYl6boCKadF1r6HQ7MRo4jtxfLzvOXv/6oqgZdj29T2H6gm803baaQoOR Jq7xEr0D1K1+Km7HQnJEP5u8Cb53p7dZnAKf7mKb6Q6RVWqnbgtUe2+/liANQ8fGAyE1 tXYw== MIME-Version: 1.0 X-Received: by 10.180.94.37 with SMTP id cz5mr21444543wib.61.1420434639096; Sun, 04 Jan 2015 21:10:39 -0800 (PST) Received: by 10.27.204.198 with HTTP; Sun, 4 Jan 2015 21:10:39 -0800 (PST) In-Reply-To: <54A8E39F.4040006@it.aoyama.ac.jp> References: <20150104015435.20842.qmail@ary.lan> <54A8E17B.5040707@it.aoyama.ac.jp> <54A8E39F.4040006@it.aoyama.ac.jp> Date: Sun, 4 Jan 2015 21:10:39 -0800 Message-ID: From: "Murray S. Kucherawy" To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=f46d04426c2c171046050be0b65c Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/joGCgmpUXvd3ln5TVzCwCsDvODA Cc: Jeff Hodges , "dbound@ietf.org" Subject: Re: [Dbound] Charter redux 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, 05 Jan 2015 05:10:42 -0000 --f46d04426c2c171046050be0b65c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 3, 2015 at 10:54 PM, "Martin J. D=C3=BCrst" wrote: > Sorry to correct myself: > > On 2015/01/04 15:45, "Martin J. D=C3=BCrst" wrote: > > Otherwise, I'm fine with the current proposal. >> > > One important issue: The document at https://github.com/equalsJeffH/dboun= d > should be submitted as an ID (and cited as such) before the charter is > finalized. > I agree that that should happen. Jeff, can you make it so? -MSK --f46d04426c2c171046050be0b65c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 3, 2015 at 10:54 PM, "Martin J. D=C3=BCrs= t" <duerst@it.aoyama.ac.jp> wrote:
= Sorry to correct myself:

On 2015/01/04 15:45, "Martin J. D=C3=BCrst" wrote:

Otherwise, I'm fine with the current proposal.

One important issue: The document at https://github.com/equalsJeffH/dbound sho= uld be submitted as an ID (and cited as such) before the charter is finaliz= ed.

I agree that that should happen.=C2= =A0 Jeff, can you make it so?

-MSK
--f46d04426c2c171046050be0b65c-- From nobody Mon Jan 5 06:56:12 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 B3F9F1A88E9 for ; Mon, 5 Jan 2015 06:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_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 PjKNP2JFmHYJ for ; Mon, 5 Jan 2015 06:56:10 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9381A88E8 for ; Mon, 5 Jan 2015 06:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1420469762; x=1421679362; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=mQWhSI8T61mu05Bru7e2KbEELix0p3d0qT5r/2V/kIQ=; b=BsSKqbweAUSXkcUidG6WOKNQzGoIsONAX4XD/Bo+DxRfZJaaxp78PHaZ gbnCg5jbZ9oupda6rPhkAjYl3oFQYqSjNdOmUs6VZJpFAKcTbcwE3Uzyt ilkJ/gC0OjP29dQ7ie02n0Og5l/wpdvCBofPQKQS0U4+gVO8lLI8e+SNL 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEAB+lqlStJssW/2dsb2JhbABcg1iDXcMbhXMCgR4BAQEBAX2EDQEBBCNVEQsYCRYLAgIJAwIBAgFFBgEMCAEBF4gRDakOk0cBAQEBAQEBAQEBAQEBAQEBAQEWBI8VEQFXgmiBQQEEj2CBJ02FNIYEi0wig289gT2BNwEBAQ X-IronPort-AV: E=Sophos;i="5.07,700,1413244800"; d="asc'?scan'208";a="295906823" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Jan 2015 14:56:00 +0000 Received: from [10.61.77.220] (ams3-vpn-dhcp3548.cisco.com [10.61.77.220]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t05EtxNH000340; Mon, 5 Jan 2015 14:55:59 GMT Message-ID: <54AAA5FF.4050001@cisco.com> Date: Mon, 05 Jan 2015 15:55:59 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, "Murray S. Kucherawy" , "dbound@ietf.org" References: <54A95658.7080002@dcrocker.net> In-Reply-To: <54A95658.7080002@dcrocker.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mqSunxeTEG3gbTUpoRJ5MMOtR7DVaFbvK" Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/o4t42UFGgznEDVEM4nBBKt4ohpQ Subject: Re: [Dbound] Charter redux 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, 05 Jan 2015 14:56:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mqSunxeTEG3gbTUpoRJ5MMOtR7DVaFbvK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the whole I'd say, "Get on with it." Let's get the thing to the IESG. But I think Dave's change is fine. Eliot On 1/4/15 4:03 PM, Dave Crocker wrote: >> https://github.com/mskucherawy/docs/blob/master/charter-dbound > > FROM: > >> However, the working >> group may discover that different solutions are needed for the email, >> web, and equivalence problems, and possibly also for other problems in= >> this space. > TO: > > However, the working group may discover that different solutions > are needed to solve different usage requirements. > > > Citing different applications presumes that apps are what might > determine the lines of demarcation between solutions. From what I've > seen, apps are merely correlate, where the real distinctions are > underlying semantics of "related" and/or different policies associated > with "related". > > Given that the working isn't starting with a single specification that > has strong support, let's not have the charter build in a potentially > distracting assumption. > > Besides that, the text I'm suggesting is shorter... > > d/ > --mqSunxeTEG3gbTUpoRJ5MMOtR7DVaFbvK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUqqX/AAoJEIe2a0bZ0nozbk4H/2lp1wS43VnSB2E4r9+Vi7Ca hvELRPpcRSSzuo0J2EZuAV7y/7pZplXFokrqS10kWSp/NlVaDznTFy5xzDB7KMbS ugf5ZYKbDNdBXClu33okGahx8eAW+QjQ8yZN7cegUfATnmE0wJnrPUM1p412ctTT iIWBDfoT+NOa5dVjR+r2ozJWHUxNkADU1cKKUZwqcnUaY31OOIa1QUo+/1EoHUaN ocLT4QaKZCGrEv3lrv3Xf5SRKq2Afa5QctJPzHM937YkBQR4ByN8hGNnVv5/k33r iKVZSOHLMTpVi8C70n6qbLMrvROqMkVcqGGUZ9XX+1KFoRrVK0zFyJeXyYKw8/A= =LfZz -----END PGP SIGNATURE----- --mqSunxeTEG3gbTUpoRJ5MMOtR7DVaFbvK-- From nobody Mon Jan 5 07:05:56 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 0E9D71A8AAA for ; Mon, 5 Jan 2015 07:05:53 -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 WFmAjUn0X5OJ for ; Mon, 5 Jan 2015 07:05:51 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B521A8A54 for ; Mon, 5 Jan 2015 07:05:38 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id p10so8070184wes.9 for ; Mon, 05 Jan 2015 07:05:37 -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=AlRODp6a9deEjjp0KBiICpaR3Ps/p5TjRG6S6FTMEBI=; b=G/1kQAX8nvUx2W1SQWGOKdoP3k/6IugSvM+rGhLxSkZ7b+qMCQjl1F9Uju4Jel7IvE b0v/MHbFQh+n4E5LU9rrNa9v1xKUK93dAuoDGEeNOFLx0sbjjYapBfSyDVa46LSZrPHm /GYAFVfSRacYaMx0UOSMqs4SyIOPHksTh201Q= 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=AlRODp6a9deEjjp0KBiICpaR3Ps/p5TjRG6S6FTMEBI=; b=N6V4mGLFZ4SUQLGC2RGiTRqXu7K8DLMhU6QWI+gKmPnDtviEmgEu37xplE33AeBMsj OnzpXSzuLEMtNgyFT5NVzfqUS7MKRKrBSUmsLbsXObIVtQkReTOV07mLO1kYA8Ezvxsc kFaaRxmjo/+2iKpB20qQsDdz53zy6E3GLYVFH5tzkJFo9ZNId7ir6hIb4fJ4to5W4Xdf m9cdp+/YH9MKIHHUGmQNHNSaRyfqdoJLfFJTCLWlJ+TvkvScKavuked8x8zATJcr60z6 QrAN6UzqnHLM+E/8BKWsY7MpHavD8OsuM+c270gkUqAQDyuwTJzVQ4vEXeJ/ByU5Uh/b zQ3g== X-Gm-Message-State: ALoCoQmIQbtIx10Xp2tNHbmVUNBYuOvFTB/3qj9l90Q8DUvtGbbIVfrU6xOI146d13WpiiVvS6F4 MIME-Version: 1.0 X-Received: by 10.181.13.7 with SMTP id eu7mr27205715wid.72.1420470336556; Mon, 05 Jan 2015 07:05:36 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.41.161 with HTTP; Mon, 5 Jan 2015 07:05:36 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Jan 2015 07:05:36 -0800 X-Google-Sender-Auth: w_IouO95OGJeQ6jQRq82ZOITPAQ Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d043be030d33501050be905c8 Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4KO7KlF54plcgnE71NaZaJ1Zf4o Cc: "dbound@ietf.org" Subject: Re: [Dbound] Charter redux 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, 05 Jan 2015 15:05:53 -0000 --f46d043be030d33501050be905c8 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 3, 2015 at 10:56 AM, Murray S. Kucherawy wrote: > > https://github.com/mskucherawy/docs/blob/master/charter-dbound > > Comments? > > -MSK > Looks good - thanks for taking the time to sort through the lingo issues. Let's kick it into gear. --Kurt Andersen --f46d043be030d33501050be905c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 3, 2015 at 10:56 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:

Look= s good - thanks for taking the time to sort through the lingo issues.=C2=A0= Let's kick it into gear.

--Kurt Andersen

--f46d043be030d33501050be905c8-- From nobody Wed Jan 7 01:01:12 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 F22DA1A1BD9 for ; Wed, 7 Jan 2015 01:01:09 -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 Wtw5xu3H5K80 for ; Wed, 7 Jan 2015 01:01:04 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88611A898C for ; Wed, 7 Jan 2015 01:01:03 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so748723wgh.37 for ; Wed, 07 Jan 2015 01:01:02 -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=93Pa4MQSY3w4kDFGJpYy6Ma4hU18cZYvL6GsTgLBk+I=; b=zwm93KXKmA1DjhITxZwYN97vjxET6j3GiF8KQTCVqGj0spkKRh2Beh5GYt8rJucE3e X7LluXwwfWgPGaH/vCjpzKlXmRRXiv1uvYrYrmEli7SZnA/3hDC3Qo1WF6w10mkdccSQ kEMDc52cB+zD9S9PznSYq5fs1XN1zIrP2HvGGle5qkpMSbGkKjCNzKBZy7rk5h5/+kjm dNCtxUSPDiIl+RFXaU/0HjGfFgPH4jMFeML2WXXbc6xxz4qMJ9yXN+8mYAZIhEtJSQYe K7KxsUG0UHiQsonI0/fW2RmYvkvAx+6uSiOJl4x+OS6xFB/6lKVRYMyA8envQaoKdptL 5+6w== MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr5203166wib.30.1420621262624; Wed, 07 Jan 2015 01:01:02 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 7 Jan 2015 01:01:02 -0800 (PST) Date: Wed, 7 Jan 2015 01:01:02 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426a60b81df9050c0c296a Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/cJyglbA5K1IzWQ6nj-jgfDFksrI Subject: [Dbound] Charter sent to IESG 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, 07 Jan 2015 09:01:10 -0000 --f46d04426a60b81df9050c0c296a Content-Type: text/plain; charset=UTF-8 Colleagues, I've sent the proposed dbound charter in its current form to Barry, and he's placed it on an IESG telechat later this month. It will go out for public review and comment before they vote on it, so there's still time to suggest and debate changes. I do feel though that it's mature enough to start the formal part of its handling. Away we go! -MSK --f46d04426a60b81df9050c0c296a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

I've sent the proposed dbound = charter in its=20 current form to Barry, and he's placed it on an IESG telechat later thi= s month.=C2=A0 It will go out for public review and comment before they vote= =20 on it, so there's still time to suggest and debate changes.=C2=A0 I do = feel=20 though that it's mature enough to start the formal part of its handling= .

Away we go!

-MSK
--f46d04426a60b81df9050c0c296a-- From nobody Wed Jan 7 06:42: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 298DB1A9082 for ; Wed, 7 Jan 2015 06:42:25 -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 JEq5E3czoRie for ; Wed, 7 Jan 2015 06:42:24 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771651A9086 for ; Wed, 7 Jan 2015 06:42:22 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so1396643igd.1 for ; Wed, 07 Jan 2015 06:42:21 -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=UVR1DyVpkXhr9zQ7L9oQHXWbt65XchnivDAKuapz4+g=; b=VdLnip+Cs0dNzx9HBAgA5ZpPd0LJQJkQBeeV5xhfbSfQEFLCRnn6yvwrf6PR/1NdoP m9eF71ElsMmoQjYOozMu6ODOmwiSp70uWWCrQ6reyscCM7wQQlEdIcaP0e8b7fHZw6eY HAr3zOfWxgI6c4ytgdXJqYw2CWxDrLD3yNCWg= 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=UVR1DyVpkXhr9zQ7L9oQHXWbt65XchnivDAKuapz4+g=; b=BZzRjqKnGnXaODcNutN/zCk7dgVW8rJUN4K3oRUdyvAIiUG+wXNlWxftpgVP8iDdEO cFO+vvPUhedekUhDrXVhgbk2y7rBNTww0HKpLAtDvIdhqGNDbzN+M0tJJTo8h/2MZ6aT CHpQ5ufNH5Ow6mSIFwh2sBQKe6FekQC3aDShJEqTTkSSG+bumEhq91plXd21Uk1g0vsZ wWMlQ5nujVKMkxTxdvRIVIONxL+dOSGgIkhYRjRiA0Cqjyq5wcFh/HDMARody+knLcMk gRXy1Pxz3cTXRvkjbS3Z49fGwOpl2WOCI8v2SrtexAipqbJV2/M3oqnk7V+Dc/n8kfkK vovw== X-Gm-Message-State: ALoCoQng8yHgvhFg0XxId2yd5fhu4/OqLEuDltCIViMmovGnkQtSfOPkR8VAgIMVlkuTNhRs5lZX MIME-Version: 1.0 X-Received: by 10.51.17.11 with SMTP id ga11mr4006041igd.0.1420641741573; Wed, 07 Jan 2015 06:42:21 -0800 (PST) Received: by 10.50.57.233 with HTTP; Wed, 7 Jan 2015 06:42:21 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Jan 2015 09:42:21 -0500 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a1135f1405c3c1c050c10eede Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/r52okXetHnZocep5Nokd0Knv6mo Subject: Re: [Dbound] Charter sent to IESG 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, 07 Jan 2015 14:42:25 -0000 --001a1135f1405c3c1c050c10eede Content-Type: text/plain; charset=UTF-8 On Wed, Jan 7, 2015 at 4:01 AM, Murray S. Kucherawy wrote: > I've sent the proposed dbound charter in its current form to Barry, and > he's placed it on an IESG telechat later this month. It will go out for > public review and comment before they vote on it, so there's still time to > suggest and debate changes. I do feel though that it's mature enough to > start the formal part of its handling. > > Away we go! > Thanks for pushing this through, Murray! Casey --001a1135f1405c3c1c050c10eede Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 7, 2015 at 4:01 AM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:
I've sent the proposed dbound charter in its=20 current form to Barry, and he's placed it on an IESG telechat later thi= s month.=C2=A0 It will go out for public review and comment before they vote= =20 on it, so there's still time to suggest and debate changes.=C2=A0 I do = feel=20 though that it's mature enough to start the formal part of its handling= .

Away we go!

Thanks for pushing this through, Murra= y!

Casey
--001a1135f1405c3c1c050c10eede-- From nobody Wed Jan 7 11:49:04 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 393D71A1A8E for ; Wed, 7 Jan 2015 11:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 qEeM0l6o8NWa for ; Wed, 7 Jan 2015 11:48:59 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8791A1A86 for ; Wed, 7 Jan 2015 11:48:59 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id f12so4155117qad.4 for ; Wed, 07 Jan 2015 11:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3y9YTD+y0C8H6IPhSMg+wXs51yvQnrzHPkP2iZM3m0U=; b=aSokiOcECBo3ngwvvK85sklFtahVDhnBdqYaxVIr+Ig5r9POKaga51XOZLKGByqjUI 0kD2tbnL4aFUYcZLI0I5GmRxGXaAq14C6NAcmImOe1z2sTakm2WgfIj8OqjEwN5/i+kG 4Ewvsivn1b3yYPsRrR9uorjYiKZqlc1TH9a6GTPcuVf/q2dIxroxhOWzlr4QaSpQFOOS +BNbIHaZa5t+yAUONCYBCRV8Gxz7ZY/8pJHKGv26Ac0+5Ok4n01klWuAoE0m1BLW48aT n+VC8+LkRLCX4v+QuGoh8+pdhQ1CqUcsgM3d+K2rn/GqK49N/Tf4+dceb+dBSfYLNI44 4AXA== X-Received: by 10.140.81.166 with SMTP id f35mr7425944qgd.0.1420660138924; Wed, 07 Jan 2015 11:48:58 -0800 (PST) Received: from new-host-3.home (pool-71-184-193-127.bstnma.fios.verizon.net. [71.184.193.127]) by mx.google.com with ESMTPSA id n5sm2054718qat.13.2015.01.07.11.48.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 11:48:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: Date: Wed, 7 Jan 2015 14:48:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <40D82B3B-6DD1-4D77-A359-37158BA747AE@gmail.com> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/906R4N03v2CEq-tBms3i2rxjmUo Cc: "dbound@ietf.org" Subject: Re: [Dbound] Charter sent to IESG 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, 07 Jan 2015 19:49:02 -0000 Yay!! Thanks Murray, and everyone who's put in time on it. On Jan 7, 2015, at 4:01 AM, Murray S. Kucherawy = wrote: > Colleagues, >=20 > I've sent the proposed dbound charter in its current form to Barry, = and he's placed it on an IESG telechat later this month. It will go out = for public review and comment before they vote on it, so there's still = time to suggest and debate changes. I do feel though that it's mature = enough to start the formal part of its handling. >=20 > Away we go! >=20 > -MSK > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound From nobody Fri Jan 9 13:28:13 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 91C8A1A0275 for ; Fri, 9 Jan 2015 13:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.5 X-Spam-Level: X-Spam-Status: No, score=-22.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, RCVD_IN_DNSWL_HI=-5, 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 GHQfYVdlSN7k for ; Fri, 9 Jan 2015 13:28:10 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017631A0041 for ; Fri, 9 Jan 2015 13:28:09 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:user-agent:x-originating-ip: Content-Type:MIME-Version:X-CFilter; b=djk7xUKPtg0TIAd/0ufvTtK65As/2ZYPBM8AC4lrZA1QuyYeRqj1Ebmy T+OTEj+bmUlcaN5hVa4Zwz3l2AWTf4OR/bQBdjCdFzWzpZIXAmAYUs5iG qmuTh0dLXHTtXX1fQZbZb/svpmQ5Dp8G9VylYPD+Q5nmDpGMc9zEdSHUm g=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1420838890; x=1452374890; h=from:to:subject:date:message-id:mime-version; bh=oGyUk3D0Nbwxm8ybPtvoqu8fX07lx5yepOsvDt6sYbs=; b=F0ZjebeUJhvARZMre8QNQ6oNRt5y8YV1xGx88MEjy7qF8MehUIp3344a 1e7wG9aRxkdGolFFOxyw6aVatun71MJ8KBXaoSN7jX2Kw0Gomct5x0yKE 3fJCzxZlkM1sUrXI4xNrlLar3HF1bBM0vN6xxdgRAbx9+e87lW6jPygP+ Y=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos; i="5.07,732,1413270000"; d="scan'208,217"; a="84813867" Received: from den-vteml-001.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 09 Jan 2015 13:28:09 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 14:28:08 -0700 From: "Hodges, Jeff" To: "dbound@ietf.org" Thread-Topic: Charter sent to IESG Thread-Index: AQHQLFMoLPDK9kLIEEujGF/Ylzs6JQ== Date: Fri, 9 Jan 2015 21:28:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.241.19.243] Content-Type: multipart/alternative; boundary="_000_D0D587FE53AF1jeffhodgespaypalcom_" MIME-Version: 1.0 X-CFilter: Scanned den1 Archived-At: Subject: Re: [Dbound] Charter sent to IESG 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, 09 Jan 2015 21:28:11 -0000 --_000_D0D587FE53AF1jeffhodgespaypalcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIG11Y2ggdG8gTXVycmF5IGZvciBwdXNoaW5nIHRoaXMgdGhyb3VnaCBhbmQgdG8gYWxs IHdobyBjb250cmlidXRlZC4NCg0KPUplZmZIDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClN1YmplY3Q6IFtEYm91bmRdIENoYXJ0ZXIgc2VudCB0byBJRVNHDQpGcm9tOiAiTXVycmF5 IFMuIEt1Y2hlcmF3eSIgPHN1cGVydXNlckBnbWFpbC5jb20+DQpEYXRlOiBXZWQsIDcgSmFuIDIw MTUgMDE6MDE6MDIgLTA4MDANClRvOiAiZGJvdW5kQGlldGYub3JnIiA8ZGJvdW5kQGlldGYub3Jn Pg0KDQpDb2xsZWFndWVzLA0KDQpJJ3ZlIHNlbnQgdGhlIHByb3Bvc2VkIGRib3VuZCBjaGFydGVy IGluIGl0cyBjdXJyZW50IGZvcm0gdG8gQmFycnksIGFuZA0KaGUncyBwbGFjZWQgaXQgb24gYW4g SUVTRyB0ZWxlY2hhdCBsYXRlciB0aGlzIG1vbnRoLiAgSXQgd2lsbCBnbyBvdXQgZm9yDQpwdWJs aWMgcmV2aWV3IGFuZCBjb21tZW50IGJlZm9yZSB0aGV5IHZvdGUgb24gaXQsIHNvIHRoZXJlJ3Mg c3RpbGwgdGltZSB0bw0Kc3VnZ2VzdCBhbmQgZGViYXRlIGNoYW5nZXMuICBJIGRvIGZlZWwgdGhv dWdoIHRoYXQgaXQncyBtYXR1cmUgZW5vdWdoIHRvDQpzdGFydCB0aGUgZm9ybWFsIHBhcnQgb2Yg aXRzIGhhbmRsaW5nLg0KDQpBd2F5IHdlIGdvIQ0KDQotTVNLDQoNCg== --_000_D0D587FE53AF1jeffhodgespaypalcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6CEFEC7DBC016342A4BF018EDD885BE6@corp.ebay.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+VGhh bmtzIG11Y2ggdG8gTXVycmF5IGZvciBwdXNoaW5nIHRoaXMgdGhyb3VnaCBhbmQgdG8gYWxsIHdo byBjb250cmlidXRlZC4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj49SmVm Zkg8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08L2Rpdj4NCjxkaXY+U3ViamVjdDogW0Rib3VuZF0gQ2hhcnRlciBzZW50IHRvIElFU0c8 L2Rpdj4NCjxkaXY+RnJvbTogJnF1b3Q7TXVycmF5IFMuIEt1Y2hlcmF3eSZxdW90OyAmbHQ7c3Vw ZXJ1c2VyQGdtYWlsLmNvbSZndDs8L2Rpdj4NCjxkaXY+RGF0ZTogV2VkLCA3IEphbiAyMDE1IDAx OjAxOjAyIC0wODAwPC9kaXY+DQo8ZGl2PlRvOiAmcXVvdDtkYm91bmRAaWV0Zi5vcmcmcXVvdDsg Jmx0O2Rib3VuZEBpZXRmLm9yZyZndDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNv bGxlYWd1ZXMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ3ZlIHNlbnQgdGhlIHBy b3Bvc2VkIGRib3VuZCBjaGFydGVyIGluIGl0cyBjdXJyZW50IGZvcm0gdG8gQmFycnksIGFuZDwv ZGl2Pg0KPGRpdj5oZSdzIHBsYWNlZCBpdCBvbiBhbiBJRVNHIHRlbGVjaGF0IGxhdGVyIHRoaXMg bW9udGguICZuYnNwO0l0IHdpbGwgZ28gb3V0IGZvcjwvZGl2Pg0KPGRpdj5wdWJsaWMgcmV2aWV3 IGFuZCBjb21tZW50IGJlZm9yZSB0aGV5IHZvdGUgb24gaXQsIHNvIHRoZXJlJ3Mgc3RpbGwgdGlt ZSB0bzwvZGl2Pg0KPGRpdj5zdWdnZXN0IGFuZCBkZWJhdGUgY2hhbmdlcy4gJm5ic3A7SSBkbyBm ZWVsIHRob3VnaCB0aGF0IGl0J3MgbWF0dXJlIGVub3VnaCB0bzwvZGl2Pg0KPGRpdj5zdGFydCB0 aGUgZm9ybWFsIHBhcnQgb2YgaXRzIGhhbmRsaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QXdheSB3ZSBnbyE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1NU0s8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D0D587FE53AF1jeffhodgespaypalcom_-- From nobody Tue Jan 13 10:37: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 AB7601A9088 for ; Tue, 13 Jan 2015 10:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 ZJm1oUiFTIaY for ; Tue, 13 Jan 2015 10:37:18 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id AC1081A9087 for ; Tue, 13 Jan 2015 10:37:18 -0800 (PST) Received: (qmail 30434 invoked by uid 0); 13 Jan 2015 18:37:17 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 13 Jan 2015 18:37:17 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id fWdE1p0092UhLwi01WdHUJ; Tue, 13 Jan 2015 11:37:17 -0700 X-Authority-Analysis: v=2.1 cv=VqmwXYGn c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=DrNGYBpgUcYA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=SojtekhEa5wA:10 a=YNv0rlydsVwA:10 a=nS36O97Bj3wUElCrIrAA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; b=GpdICHlVii4fYkHN+DL3vWNl/HuJqia+WOHVmDwiIGFcTC9fbQSddzXg6VOuEfantLMql6Tl0nxv1E6pltAGlcCtRqPDd1uT0DFYhWWLPm1JkhjNy36xi9C2GWEa2WTh; Received: from [216.113.160.66] (port=47505 helo=[10.244.137.7]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YB6L4-0005rV-Af for dbound@ietf.org; Tue, 13 Jan 2015 11:37:14 -0700 Message-ID: <54B565D6.2070701@KingsMountain.com> Date: Tue, 13 Jan 2015 10:37:10 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dbound@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.160.66 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Dbound] test pls ignore 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, 13 Jan 2015 18:37:20 -0000 test From nobody Tue Jan 13 15:00:03 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 042B51B2AA4; Tue, 13 Jan 2015 14:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 qpYFmSguSUes; Tue, 13 Jan 2015 14:59:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9621B2A99; Tue, 13 Jan 2015 14:59:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 14:59:44 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 22:59:56 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-dbound-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had one suggestion. This charter is fairly chatty (which is fine), including examples, but after reading it, I wasn't sure whether I'd be able to tell whether ibm.com and ibm.co.uk were related. I think the answer is "yes", but the charter might be clearer if it used an example like that. From nobody Tue Jan 13 15:05:37 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 410281B2AF6; Tue, 13 Jan 2015 15:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 gEp6U5CrjfI8; Tue, 13 Jan 2015 15:05:29 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AABD1B2B11; Tue, 13 Jan 2015 15:05:05 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8223A8A031; Tue, 13 Jan 2015 23:05:04 +0000 (UTC) Date: Tue, 13 Jan 2015 18:05:03 -0500 From: Andrew Sullivan To: Spencer Dawkins Message-ID: <20150113230502.GL60601@mx1.yitter.info> References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 13 Jan 2015 23:05:30 -0000 On Tue, Jan 13, 2015 at 02:59:44PM -0800, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I had one suggestion. This charter is fairly chatty (which is fine), > including examples, but after reading it, I wasn't sure whether I'd be > able to tell whether ibm.com and ibm.co.uk were related. > > I think the answer is "yes", but the charter might be clearer if it used > an example like that. Actually, that's one of the questions the WG has to answer, but perhaps pointing out that _that_ is a deliverable would be good? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jan 13 15:10: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 A773A1B2B86; Tue, 13 Jan 2015 15:10:09 -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 HJGpSUiFG1bo; Tue, 13 Jan 2015 15:10:07 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD771B2B7A; Tue, 13 Jan 2015 15:09:27 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so5174746lbj.8; Tue, 13 Jan 2015 15:09:26 -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=MObTokWkAcSBBSOYDwEvVfllweeXwiF48xOAT2tNxj8=; b=fftY+UvqQH5u1YbKkidvldfcNr2jDIqqzLPhi1hrwthoMH0DAUoK0ZoYbEaONgtZKH wDdDffNUvEoUspg5wC53nIbiTb8gkMyXvIleS+FhFZCxooAWgWM2LmjEVUWJhkCJg+kB /ko+WwV3iavzZIzvZBFCy0K6SJ/WYWJ2CjmLeToI55RamMJVwM8lOebQCJZBShU/J9z7 tH2W8VYHqg+kewgnxRDE6S0cGHW1yg1Y0VFl0sZTouDaqohLg+6bXwmnD9UBy57RrrYl Vy8htrzEcqUev8yW0Kw6YiL31YQFZXEJRzc4IPAe59wBS5xKhfIUgrLzYB3QH671wCzB PvTQ== MIME-Version: 1.0 X-Received: by 10.112.50.239 with SMTP id f15mr770293lbo.31.1421190566182; Tue, 13 Jan 2015 15:09:26 -0800 (PST) Received: by 10.152.185.195 with HTTP; Tue, 13 Jan 2015 15:09:26 -0800 (PST) In-Reply-To: <20150113230502.GL60601@mx1.yitter.info> References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <20150113230502.GL60601@mx1.yitter.info> Date: Tue, 13 Jan 2015 17:09:26 -0600 Message-ID: From: Spencer Dawkins at IETF To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a113368d4db02ae050c90b6de Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 13 Jan 2015 23:10:09 -0000 --001a113368d4db02ae050c90b6de Content-Type: text/plain; charset=UTF-8 Hi, Andrew, On Tue, Jan 13, 2015 at 5:05 PM, Andrew Sullivan wrote: > On Tue, Jan 13, 2015 at 02:59:44PM -0800, Spencer Dawkins wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I had one suggestion. This charter is fairly chatty (which is fine), > > including examples, but after reading it, I wasn't sure whether I'd be > > able to tell whether ibm.com and ibm.co.uk were related. > > > > I think the answer is "yes", but the charter might be clearer if it used > > an example like that. > > Actually, that's one of the questions the WG has to answer, but > perhaps pointing out that _that_ is a deliverable would be good? That would work for me! (I'm not sure if I said this clearly - I meant that you'd be able to tell whether ibm.com and ibm.co.uk were related, or not, not that they obviously were. Sorry if I was more confused/confusing than usual. Spencer > > --001a113368d4db02ae050c90b6de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Andrew,

On Tue, Jan 13, 2015 at 5:05 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Tue, Jan 13, 2015 at 02:59:44PM -0800, Spencer Dawkin= s wrote:
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I had one suggestion. This charter is fairly chatty (which is fine), > including examples, but after reading it, I wasn't sure whether I&= #39;d be
> able to tell whether ibm.= com and ibm.co.uk we= re related.
>
> I think the answer is "yes", but the charter might be cleare= r if it used
> an example like that.

Actually, that's one of the questions the WG has to answer, but<= br> perhaps pointing out that _that_ is a deliverable would be good?

That would work for me!

(I&#= 39;m not sure if I said this clearly - I meant that you'd be able to te= ll whether ibm.com and ibm.co.uk were related, or not, not that they obviously were. S= orry if I was more confused/confusing than usual.

= Spencer
=C2=A0
--001a113368d4db02ae050c90b6de-- From nobody Tue Jan 13 15:11:18 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 394F51B2B7D; Tue, 13 Jan 2015 15:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yXw2wAxC2kvs; Tue, 13 Jan 2015 15:11:12 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070FA1B2B8F; Tue, 13 Jan 2015 15:10:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7ABACBEDF; Tue, 13 Jan 2015 23:10:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-XhwtwP7Eiz; Tue, 13 Jan 2015 23:10:15 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.54.55]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C071BECA; Tue, 13 Jan 2015 23:10:15 +0000 (GMT) Message-ID: <54B5A5D6.2080207@cs.tcd.ie> Date: Tue, 13 Jan 2015 23:10:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> In-Reply-To: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 13 Jan 2015 23:11:15 -0000 I'll send a proper ballot but I also found the text so verbose it started to be counterproductive. It also started off a bit too abstract I think, perhaps leading to Richard's confusion. I'd suggest trying to start from something like "We need the PSL but it's known to be problematic so better solutions are needed, ideally one, but maybe more." It's ok IMO if someone who doesn't know what the PSL is has to wait a short paragraph to be told. S. On 13/01/15 22:59, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-dbound-00-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-dbound/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I had one suggestion. This charter is fairly chatty (which is fine), > including examples, but after reading it, I wasn't sure whether I'd be > able to tell whether ibm.com and ibm.co.uk were related. > > I think the answer is "yes", but the charter might be clearer if it used > an example like that. > > From nobody Tue Jan 13 15:47: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 30A581ACDF6; Tue, 13 Jan 2015 15:47:39 -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 kYigrNIM6ns8; Tue, 13 Jan 2015 15:47:37 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19D91ACDBE; Tue, 13 Jan 2015 15:47:36 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so5849394wes.2; Tue, 13 Jan 2015 15:47:35 -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=oDxLlXq98oOTsGQkhOARzF1D/jXmq0rh1CSYbe9hlao=; b=cWRmqX6O9ZDweE+GofXWUN2RBvA9UU9iMqPNtRwz7vNG22i4bGmEi0l1RKyJ4vqGhC 7vBp/5K+ZRKmjwUYEotSmNH8fgr5GA/iBXtSeFBkps7ZjOkK00rP+TAUslEIARlbc1D7 i4yPdH4X12hVsLoeDTi8vCXl/5dqpOcbfczYXcVv52mLk3LG8ZAmHbypvbDbf7yrEMYO qFqieWlkejh3X6ysBVmEpzmF5KAsbLGMC7KgAfrugvzEqAJgnBpdQ3jGWPd2jT8wSVQy C6ZopEz0TCU8HVaMTHpZXZ/0PypQKkEqke4po5tWMn2N3dfz5rDJwrz01xgnXG0W9Egt cxlg== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr1470538wjz.89.1421192855735; Tue, 13 Jan 2015 15:47:35 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 13 Jan 2015 15:47:35 -0800 (PST) In-Reply-To: <54B5A5D6.2080207@cs.tcd.ie> References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <54B5A5D6.2080207@cs.tcd.ie> Date: Tue, 13 Jan 2015 15:47:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0102e49852d82f050c913fab Archived-At: Cc: "dbound@ietf.org" , Spencer Dawkins , The IESG Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 13 Jan 2015 23:47:39 -0000 --089e0102e49852d82f050c913fab Content-Type: text/plain; charset=UTF-8 Hi Stephen, On Tue, Jan 13, 2015 at 3:10 PM, Stephen Farrell wrote: > I'll send a proper ballot but I also found the text so verbose > it started to be counterproductive. It also started off a bit > too abstract I think, perhaps leading to Richard's confusion. > > I'd suggest trying to start from something like "We need the PSL > but it's known to be problematic so better solutions are needed, > ideally one, but maybe more." > > It's ok IMO if someone who doesn't know what the PSL is has to > wait a short paragraph to be told. We struggled quite a bit to figure out how much background is needed in the charter for this work. What you're looking at is the result even after we sliced it up some. I imagine it's just hard to gauge what the right amount of background is: Are we writing this for an IESG we assume is already somewhat familiar with the problem space, or for the general community which might not be? Happy to hear suggestions about how it could be more brief but still generally meaningful. -MSK --089e0102e49852d82f050c913fab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Tue, Jan 13, 2015 at 3:10 PM, Stephe= n Farrell <stephen.farrell@cs.tcd.ie> wrote:
I'll send a proper ballot but I also found the text so verbose it started to be counterproductive. It also started off a bit
too abstract I think, perhaps leading to Richard's confusion.

I'd suggest trying to start from something like "We need the PSL but it's known to be problematic so better solutions are needed,
ideally one, but maybe more."

It's ok IMO if someone who doesn't know what the PSL is has to
wait a short paragraph to be told.

We strug= gled quite a bit to figure out how much background is needed in the charter= for this work.=C2=A0 What you're looking at is the result even after w= e sliced it up some.=C2=A0 I imagine it's just hard to gauge what the r= ight amount of background is:=C2=A0 Are we writing this for an IESG we assu= me is already somewhat familiar with the problem space, or for the general = community which might not be?

Happy to hear suggestions a= bout how it could be more brief but still generally meaningful.

-MSK
--089e0102e49852d82f050c913fab-- From nobody Tue Jan 13 16:51:43 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 3AE911B2C11; Tue, 13 Jan 2015 16:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 dTCAlqSj1nCN; Tue, 13 Jan 2015 16:51:38 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75841ACE51; Tue, 13 Jan 2015 16:51:37 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so5508132lbi.2; Tue, 13 Jan 2015 16:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0aS5WVtt1gSyK0I8hXgs82rpPGyDeI5xDr7O0rFe7RQ=; b=NYX4pPLNRivMYY47j/crA8toXj9O/O2Ub++YyfKd/uro45LLn/zYQRLQyMSriQ0Rvy rsXatFq9uHwhcmvSe+AUzG6EmCmth7hqqOUncUbwaFlZiTIJ6fuHHG+TzV8Mm23ZoWq7 ZOBkZHzXwRe04E2aX6iznCXMyT65TIz08+x5z1a3mdAXuy4s24po7Gno1qELCycbrfTb EE0hmmGD93DVysZatsD6LcgkTU1Ja2/6h+XjymC7UliShx6HfdcaoKVKS7CSzicCAz/R mkImuhQiHKPQXXsYgar47fOS+BT684EfYZSet4CwC+aL9PT0Q5PyVgjXNUB5qU65WRii aUVw== MIME-Version: 1.0 X-Received: by 10.152.87.142 with SMTP id ay14mr1063850lab.45.1421196696192; Tue, 13 Jan 2015 16:51:36 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 13 Jan 2015 16:51:36 -0800 (PST) In-Reply-To: References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <54B5A5D6.2080207@cs.tcd.ie> Date: Tue, 13 Jan 2015 19:51:36 -0500 X-Google-Sender-Auth: hXH3417v5-zMJXtjURQFZS57Of4 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: The IESG , "dbound@ietf.org" , Spencer Dawkins , Stephen Farrell Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 00:51:39 -0000 > We struggled quite a bit to figure out how much background is needed in the > charter for this work. What you're looking at is the result even after we > sliced it up some. I imagine it's just hard to gauge what the right amount > of background is: Are we writing this for an IESG we assume is already > somewhat familiar with the problem space, or for the general community which > might not be? > > Happy to hear suggestions about how it could be more brief but still > generally meaningful. You could move even more to the "additional background" section, perhaps (or perhaps not) with an additional citation or two that sends people there to look. I plan, when the WG is created, to move that section out of the charter and into the WG wiki (and to replace the citation(s) to point to the wiki). Barry From nobody Tue Jan 13 17:23:37 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 39A341ACE42; Tue, 13 Jan 2015 17:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 JOjqcnRYWI1m; Tue, 13 Jan 2015 17:23:29 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99841ACE40; Tue, 13 Jan 2015 17:23:29 -0800 (PST) Received: from [192.168.19.2] (m9d0536d0.tmodns.net [208.54.5.157]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0E1NIZU031241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 17:23:25 -0800 Message-ID: <54B5C4F9.20302@dcrocker.net> Date: Tue, 13 Jan 2015 17:23:05 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Sullivan , Spencer Dawkins References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <20150113230502.GL60601@mx1.yitter.info> In-Reply-To: <20150113230502.GL60601@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 13 Jan 2015 17:23:26 -0800 (PST) Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:23:31 -0000 On 1/13/2015 3:05 PM, Andrew Sullivan wrote: > hat's one of the questions the WG has to answer, but > perhaps pointing out that _that_ is a deliverable would be good? +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 13 17:30:18 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 D1C2B1ACE42; Tue, 13 Jan 2015 17:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 JUae4o6zxdGX; Tue, 13 Jan 2015 17:30:14 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672171ACE27; Tue, 13 Jan 2015 17:30:14 -0800 (PST) Received: from [192.168.19.2] (m9d0536d0.tmodns.net [208.54.5.157]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0E1TuXH031347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 17:30:02 -0800 Message-ID: <54B5C687.9010401@dcrocker.net> Date: Tue, 13 Jan 2015 17:29:43 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , "Murray S. Kucherawy" References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <54B5A5D6.2080207@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 13 Jan 2015 17:30:04 -0800 (PST) Archived-At: Cc: Stephen Farrell , Spencer Dawkins , The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:30:16 -0000 On 1/13/2015 4:51 PM, Barry Leiba wrote: > I plan, when the WG is created, to move that section out of the > charter and into the WG wiki (and to replace the citation(s) to point > to the wiki). Interesting thought. A similar model -- base + wiki -- recently came up in a separate-but-unrelated discussion for a document. The challenge here is whether moving background material out of the charter creates a barrier that matters. The reason for the extra material in this charter is that the topic itself is relatively new, relatively poorly understood, and does not have readily apparent and easy solution. All of that creates a need to level-set readers of the charter. It might seem that one click to the wiki is no big deal, but it does create a meaningful barrier. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 13 18:20:29 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 DBEC71ACE0F for ; Tue, 13 Jan 2015 18:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V-bqCJ1-0lzs for ; Tue, 13 Jan 2015 18:20: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 A3A8B1A89A5 for ; Tue, 13 Jan 2015 18:20:24 -0800 (PST) Received: (qmail 13727 invoked from network); 14 Jan 2015 02:20:23 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jan 2015 02:20:23 -0000 Date: 14 Jan 2015 02:20:01 -0000 Message-ID: <20150114022001.23309.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <20150113230502.GL60601@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 02:20:26 -0000 >> I had one suggestion. This charter is fairly chatty (which is fine), >> including examples, but after reading it, I wasn't sure whether I'd be >> able to tell whether ibm.com and ibm.co.uk were related. >> >> I think the answer is "yes", but the charter might be clearer if it used >> an example like that. > >Actually, that's one of the questions the WG has to answer, but >perhaps pointing out that _that_ is a deliverable would be good? It is certainly a question we would like to be able to answer, but at this point we don't know whether we have a technically feasible way to do it. The hardest part of the DBOUND work is balancing what we'd like to do with what we are able to do. If we have a design that answers many questions, but can't answer this one, does that mean we have to give up? R's, John From nobody Wed Jan 14 07:35: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 67EEE1A886C for ; Wed, 14 Jan 2015 07:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 v5OI0YI-vPgD for ; Wed, 14 Jan 2015 07:35:16 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9C41A8707 for ; Wed, 14 Jan 2015 07:35:16 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0EFZBF6009279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 07:35:15 -0800 Message-ID: <54B68CA2.6060209@dcrocker.net> Date: Wed, 14 Jan 2015 07:34:58 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dbound@ietf.org References: <20150114022001.23309.qmail@ary.lan> In-Reply-To: <20150114022001.23309.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 14 Jan 2015 07:35:15 -0800 (PST) Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 15:35:18 -0000 The nature of this sub-thread has prompted me to wonder at an unfortunate question: Is this topic ready for standardization work? It feels as if it is more appropriate for the IRTF, at this point, until we have a much better understanding of what can/should be done and why and until there's a reasonable community understanding of those answers. d/ On 1/13/2015 6:20 PM, John Levine wrote: >>> I had one suggestion. This charter is fairly chatty (which is fine), >>> including examples, but after reading it, I wasn't sure whether I'd be >>> able to tell whether ibm.com and ibm.co.uk were related. >>> >>> I think the answer is "yes", but the charter might be clearer if it used >>> an example like that. >> >> Actually, that's one of the questions the WG has to answer, but >> perhaps pointing out that _that_ is a deliverable would be good? > > It is certainly a question we would like to be able to answer, but at > this point we don't know whether we have a technically feasible way to > do it. > > The hardest part of the DBOUND work is balancing what we'd like to do > with what we are able to do. If we have a design that answers many > questions, but can't answer this one, does that mean we have to give > up? -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 14 09:25: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 51B211A911A for ; Wed, 14 Jan 2015 09:25:03 -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 xCGi_AOw2-Ff for ; Wed, 14 Jan 2015 09:25:02 -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 CE5261A90F0 for ; Wed, 14 Jan 2015 09:25:01 -0800 (PST) Received: (qmail 32830 invoked from network); 14 Jan 2015 17:25:00 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jan 2015 17:25:00 -0000 Date: 14 Jan 2015 17:24:38 -0000 Message-ID: <20150114172438.26700.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <54B68CA2.6060209@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 17:25:03 -0000 In article <54B68CA2.6060209@dcrocker.net> you write: >The nature of this sub-thread has prompted me to wonder at an >unfortunate question: > > Is this topic ready for standardization work? >From what I've seen in the skirmishes so far, if we could agree on a concrete problem, we could probably come up with a design to address it. But there is little agreement on what the problem is or problems are, and it often seems that people don't even appreciate how different the applications are into which the PSL has been shoehorned, both technically and administratively. There also seems to be a sentiment that this is an important problem, therefore we must solve it now. Add metaphors to bells and cats as desired. R's, John From nobody Wed Jan 14 09:29:17 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 15C1F1A90E9 for ; Wed, 14 Jan 2015 09:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 pYnOEk7EDYP7 for ; Wed, 14 Jan 2015 09:29:12 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F2E1A9127 for ; Wed, 14 Jan 2015 09:29:11 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7A89B8A035 for ; Wed, 14 Jan 2015 17:29:00 +0000 (UTC) Date: Wed, 14 Jan 2015 12:28:59 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150114172858.GD62370@mx1.yitter.info> References: <20150113230502.GL60601@mx1.yitter.info> <20150114022001.23309.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150114022001.23309.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 17:29:14 -0000 On Wed, Jan 14, 2015 at 02:20:01AM -0000, John Levine wrote: > >> I had one suggestion. This charter is fairly chatty (which is fine), > >> including examples, but after reading it, I wasn't sure whether I'd be > >> able to tell whether ibm.com and ibm.co.uk were related. > >> > >> I think the answer is "yes", but the charter might be clearer if it used > >> an example like that. > > > >Actually, that's one of the questions the WG has to answer, but > >perhaps pointing out that _that_ is a deliverable would be good? > > It is certainly a question we would like to be able to answer, but at > this point we don't know whether we have a technically feasible way to > do it. Apparently once again speaking quickly fails me. What I meant was, the question Spencer was putting -- "Would I be able to tell whether these two are related?" is one of the open questions. It would be nice to make the answer, "Yes, here's how they're related," but I agree that we don't know whether that's feasible or high enough priority. Again, however, I don't think that's a question to _answer_ in the charter, but to pose. It's a working group, after all. It can do some work. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jan 14 09:33:59 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 B73FD1A90E9 for ; Wed, 14 Jan 2015 09:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 l67_5RTtycaz for ; Wed, 14 Jan 2015 09:33:57 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0591A9126 for ; Wed, 14 Jan 2015 09:33:57 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D77668A035 for ; Wed, 14 Jan 2015 17:33:55 +0000 (UTC) Date: Wed, 14 Jan 2015 12:33:54 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150114173354.GE62370@mx1.yitter.info> References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B68CA2.6060209@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 17:33:58 -0000 Hi Dave, On Wed, Jan 14, 2015 at 07:34:58AM -0800, Dave Crocker wrote: > > It feels as if it is more appropriate for the IRTF, at this point, Since feelings are private states, and since I don't have the same feeling as you, perhaps you could construct an argument instead? > until we have a much better understanding of what can/should be done and > why and until there's a reasonable community understanding of those answers. To be clear, I didn't think that was an argument; it's just assertions of missing understanding. I think we know that there is an array of issues that all arise from treating the domain names a certain way, and we know that at least some of those treatments are at best approximations for the actual intent. There's a problem statement that outlines this; and indeed we've even had two different proposals for what to do, which revealed that there appear to be at least two different styles of need. What is not apparent is whether these can be handled by a single system, nor whether they're all actually cases of the same desire or in fact different desires that happen to be using the same existing technology. I _hope_ we don't need to treat that sort of question as a RG problem. If so, then there's no excuse for WGs at all: they'd just be an expensive way of processing a predetermined conclusion through a group of observers. That sounds like a massive waste of time to me. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jan 14 10:26: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 CA7EC1ACCD9 for ; Wed, 14 Jan 2015 10:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 lDOtbNS-jZWs for ; Wed, 14 Jan 2015 10:26:00 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D349D1ACC8B for ; Wed, 14 Jan 2015 10:25:56 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id v8so7795600qal.8 for ; Wed, 14 Jan 2015 10:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=OKxIznq+VYaM3zpWCYxMB8lLTDS9Sv0wUfKRtcwVcGo=; b=doURURPqMZUfFqwiUwrC1ywHud4FrIJ501i1gTbQrB+e9G9y+AL3mfr2joCwVEL8Ly ez/GUUEKN3OcyN4TplUP/l1bgiL+TFiNpAbJJfS562McI/WpGTuoVF67PVhl8bOBB50h TcYThEwJb1gdoc482YunZEMd0lIyWpgXjKKBfbm3D5/+f4MhhJttOhkMZiBxQE0a9oI9 rqcSSk5247x4z1qh2a/1/of+aq8DoFOw18z8Db6/cZELcq+jU7jOyQD0Bw2l7psgSobf EkUlGZDWPg7yS6yfk6NddTqZKsd/WIFkYgWmkSqj4YtDRLWZTdxZ0bXeZQ/SDj9rpflK 1Vqw== X-Received: by 10.140.81.71 with SMTP id e65mr8618955qgd.82.1421259955904; Wed, 14 Jan 2015 10:25:55 -0800 (PST) Received: from [10.0.0.5] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by mx.google.com with ESMTPSA id k9sm21215294qaj.7.2015.01.14.10.25.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 10:25:54 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <20150114173354.GE62370@mx1.yitter.info> Date: Wed, 14 Jan 2015 13:25:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <10965715-25DD-46DD-8BE9-3EB674037FE7@gmail.com> References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> <20150114173354.GE62370@mx1.yitter.info> To: Andrew Sullivan , "dbound@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 14 Jan 2015 18:26:01 -0000 Hi, On Jan 14, 2015, at 12:33 PM, Andrew Sullivan = wrote: > I think we know that there is an array of issues that all arise from > treating the domain names a certain way, and we know that at least > some of those treatments are at best approximations for the actual > intent. There's a problem statement that outlines this; and indeed > we've even had two different proposals for what to do, which revealed > that there appear to be at least two different styles of need. >=20 > What is not apparent is whether these can be handled by a single > system, nor whether they're all actually cases of the same desire or > in fact different desires that happen to be using the same existing > technology. =20 FWIW, this matches my understanding of why people have been putting = significant effort into trying to spin up a WG. Even a result of "No, this isn't a problem or set of problems that can = be characterized or solved from this direction" can be useful-- see for = example (and I may well regret this, but=85.) the discussions of = "equivalence" across DNS names.=20 Suzanne From nobody Wed Jan 14 14:57:46 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 AEC521AD09D for ; Wed, 14 Jan 2015 14:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 c9o1NcaUX9XT for ; Wed, 14 Jan 2015 14:57:41 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71F71ACF58 for ; Wed, 14 Jan 2015 14:57:41 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0EMva7b018451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 14:57:39 -0800 Message-ID: <54B6F453.1070402@dcrocker.net> Date: Wed, 14 Jan 2015 14:57:23 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> <20150114173354.GE62370@mx1.yitter.info> In-Reply-To: <20150114173354.GE62370@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 14 Jan 2015 14:57:40 -0800 (PST) Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 22:57:43 -0000 On 1/14/2015 9:33 AM, Andrew Sullivan wrote: > Hi Dave, > > On Wed, Jan 14, 2015 at 07:34:58AM -0800, Dave Crocker wrote: >> >> It feels as if it is more appropriate for the IRTF, at this point, > > perhaps you could construct an argument instead? Sure. (For reference, I think this topic is important and I'd love to see this sort of enhancement for the DNS.) My concern is that the current state of the topic does not bode well either for producing a highly useful enhancement or for its getting adopted and used: 1. We have some experience with working group efforts that succeed and others that fail. We even have some documentation about this. My summary is that the safest approach for working group success is to start the standards process when there is: * good and shared understanding of the problem space * reasonably good and shared understanding of the solution space, where a concrete specification that folks resonate with is especially helpful and, obviously even better when there's some running code for it * strong community pressure to adopt the work * solid promise of substantial community participation in the work. There are all sorts of heuristics for gauging the above, for a given effort, but the current topic is not faring all that well, IMO. I've no doubt that there are a few folk who are certain they understand the topic, and the solution choices, but I don't see that clarity showing up broadly, in community terms. (For some reason, I keep thinking that our using the word 'related' as a core label indicates the vagueness of our understanding, even though I think the work is quite accurate for the scope of what is intended.) 2. The DNS community, in particular, has been highly resistant to substantive changes over the last 25 years. As such, an effort to add a capability of such conceptual note as DBound intends strikes me as needing particular strong signs of satisfying the above bulleted list. 3. The current drafts are useful documents, but I believe they are quite some distance from garnering community consensus and, even more importantly, community adoption pressure. 4. A particularly good heuristic for community interest is mailing list activity. We are not doing well in that regard. The list is probably longer, but that seems enough for now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 14 18:47: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 B8FF91B2AA8 for ; Wed, 14 Jan 2015 18:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 teyOiC1YPFDQ for ; Wed, 14 Jan 2015 18:47:15 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08D1ACED1 for ; Wed, 14 Jan 2015 18:47:14 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 215828A035 for ; Thu, 15 Jan 2015 02:47:13 +0000 (UTC) Date: Wed, 14 Jan 2015 21:47:11 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150115024711.GD59044@mx1.yitter.info> References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> <20150114173354.GE62370@mx1.yitter.info> <54B6F453.1070402@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B6F453.1070402@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 15 Jan 2015 02:47:16 -0000 On Wed, Jan 14, 2015 at 02:57:23PM -0800, Dave Crocker wrote: > * good and shared understanding of the problem space I think that, to the extent we do not have such a good understanding, we are nevertheless approaching it. I guess you perceive this differently. > * reasonably good and shared understanding of the solution space, > where a concrete specification that folks resonate with is especially > helpful and, obviously even better when there's some running code for it Our biggest problem seems to be that today, there are two techniques and they both seem to have corners that don't work well for the other technique. But that seems to me to be exactly the sort of thorny problem that a WG is needed to tackle. Otherwise, we'll have two ways of doing "the same" thing depending on what kind of application you're using, and that will be the source of subtle bugs. > * strong community pressure to adopt the work We seem to have participation from vendors like PayPal, DNS operators like ICANN and (for that matter) my employer, and browser developers like Firefox and Chrome. Perhaps this isn't "strong" pressure, but it's not nothing. > broadly, in community terms. (For some reason, I keep thinking that our > using the word 'related' as a core label indicates the vagueness of our > understanding, even though I think the work is quite accurate for the > scope of what is intended.) Right. It's a big topic. In my opinion, making it smaller just so that we can claim it's more concrete would not help. > 2. The DNS community, in particular, has been highly resistant to > substantive changes over the last 25 years. I think your claim is unfair. You're talking about the same community that has built and to some extent (more than v6, anyway) deployed DNSSEC, and that has consistently and enthusiastically participated in DANE. There certainly are nay-sayers among the DNS community whenever one suggests anything that represents thinking different than that in RFC 2181, but it's not everyone. Wouldn't you agree? > 3. The current drafts are useful documents, but I believe they are > quite some distance from garnering community consensus and, even more > importantly, community adoption pressure. Is this a suggestion that those of us who have worked on those drafts would be better to go away, and get them more or less done, and then come back to the IETF? If so, what is the reason for the "come back to the IETF" step? Why would someone do that? > 4. A particularly good heuristic for community interest is mailing list > activity. We are not doing well in that regard. It is true that this list has not been hugely active. I can take some of the blame -- I've been busy and have not been tackling the updates as quickly as I should have been, partly because there seemed in Honolulu to be a desire to try to work the WG process instead. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jan 14 19:52:15 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 4D1791B2AEF for ; Wed, 14 Jan 2015 19:52:13 -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 mTmAc6Lh6gwQ for ; Wed, 14 Jan 2015 19:52:10 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36071B2AEC for ; Wed, 14 Jan 2015 19:52:09 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so12527732wgh.9 for ; Wed, 14 Jan 2015 19:52:08 -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=8c/LDao18L+zcQMCQgQL1EOZGrx4IDC0R7IVm9KzXVw=; b=fJS4+jpisdrbhGgWZ5/6KihMuEr1NsgwFxpKTtlzb9aWjYoBqoQfug3v6hzw/EdyY0 IU3TQhgQj7uT1K2xt2R6Urpz/Od7pxTtLVIhAfHxu/fTybGm8dgPTdG9X4Z9D+Q04u0q bg780mcDTLqf4uOdgDuwyb1z3j9sBoIko0lYhPInAdT4VAfIrHq4iPnp2DNX3kbx58CP 8mFQvHlpD5oD6Ozl2JmBxGyWu9CzDCjgRz6lXxNgyVr3sS6C7waiQJ+WJfjrheTuKTrx 4LFDKEUbaQovr8cAObOCrw/DQibgQsasvgZouKWNCbIRF4P4xt36cu/B9ZCxDdXPiPhc vQIg== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr13686464wjr.5.1421293928623; Wed, 14 Jan 2015 19:52:08 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 14 Jan 2015 19:52:08 -0800 (PST) In-Reply-To: <54B6F453.1070402@dcrocker.net> References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> <20150114173354.GE62370@mx1.yitter.info> <54B6F453.1070402@dcrocker.net> Date: Wed, 14 Jan 2015 19:52:08 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7ba977a4bcb655050ca8c78b Archived-At: Cc: Andrew Sullivan , "dbound@ietf.org" Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 15 Jan 2015 03:52:13 -0000 --047d7ba977a4bcb655050ca8c78b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 2:57 PM, Dave Crocker wrote: > 1. We have some experience with working group efforts that succeed and > others that fail. We even have some documentation about this. > > My summary is that the safest approach for working group success is > to start the standards process when there is: > > * good and shared understanding of the problem space > > * reasonably good and shared understanding of the solution space, > where a concrete specification that folks resonate with is especially > helpful and, obviously even better when there's some running code for it > > * strong community pressure to adopt the work > > * solid promise of substantial community participation in the work. > > There are all sorts of heuristics for gauging the above, for a given > effort, but the current topic is not faring all that well, IMO. I've no > doubt that there are a few folk who are certain they understand the > topic, and the solution choices, but I don't see that clarity showing up > broadly, in community terms. (For some reason, I keep thinking that our > using the word 'related' as a core label indicates the vagueness of our > understanding, even though I think the work is quite accurate for the > scope of what is intended.) > I've been thinking about these points in comparison to other successful IETF work in which I've participated. The example I keep coming back to is WEIRDS. WEIRDS had a basic goal, namely the replacement of WHOIS with something more modern. However, it had two very different use cases, names and numbers, and there was enormous pressure to keep them separate in order not to burden one side (which had even developed to prototype implementing their proposed solution) with the political baggage of the other. There was even an insistence that a "nuclear option" be included in the charter, granting the co-chairs the right to jettison the problematic use case if it seemed to be blocking the other one. Nevertheless, by all accounts I've heard, WEIRDS was a success in that it did manage to come up with a single solution to both use cases, which is now in the RFC Editor queue. Back to the DBOUND work: I believe that, even though we again have two primary use cases here, the community active in this charter's development does satisfy the points you've addressed, as long as "space" can be interpreted as "spaces, for which there is some amount of common space". Given, in particular, that the highly energetic DMARC community is hungry for the output of this working group, I don't have any concerns that this work will draw sufficient attention once it gets rolling. Someone else (Jeff, perhaps?) will need to comment on the web community's likelihood of participation for that use case. 2. The DNS community, in particular, has been highly resistant to > substantive changes over the last 25 years. As such, an effort to add a > capability of such conceptual note as DBound intends strikes me as > needing particular strong signs of satisfying the above bulleted list. > We do say in the charter that we're constrained against anything in terms of DNS changes other than registering new RRTYPEs. The bar has been lower for that of late, as I understand it. > 3. The current drafts are useful documents, but I believe they are > quite some distance from garnering community consensus and, even more > importantly, community adoption pressure. > Do initial documents need to have consensus that they're ready to go, or just that they are reasonable starting points for development? I was under the impression that this community agrees that one or both of the documents already satisfy the latter criterion. > 4. A particularly good heuristic for community interest is mailing list > activity. We are not doing well in that regard. > I get the impression that this is because the list lately has been dominated by IETF sausage-making rather than actual technological discussion. That doesn't have to be the case, but it might be the assumption some people are making. By all means, if there's momentum to do technical development while others are hacking on the charter, people should feel free to do so. -MSK --047d7ba977a4bcb655050ca8c78b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 14, 2015 at 2:57 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
1. We have some experience with wo= rking group efforts that succeed and
others that fail.=C2=A0 We even have some documentation about this.

=C2=A0 =C2=A0My summary is that the safest approach for working group succe= ss is
to start the standards process when there is:

=C2=A0 =C2=A0*=C2=A0 good and shared understanding of the problem space

=C2=A0 =C2=A0*=C2=A0 reasonably good and shared understanding of the soluti= on space,
where a concrete specification that folks resonate with is especially
helpful and, obviously even better when there's some running code for i= t

=C2=A0 =C2=A0*=C2=A0 strong community pressure to adopt the work

=C2=A0 =C2=A0*=C2=A0 solid promise of substantial community participation i= n the work.

=C2=A0 =C2=A0There are all sorts of heuristics for gauging the above, for a= given
effort, but the current topic is not faring all that well, IMO. I've no=
doubt that there are a few folk who are certain they understand the
topic, and the solution choices, but I don't see that clarity showing u= p
broadly, in community terms.=C2=A0 (For some reason, I keep thinking that o= ur
using the word 'related' as a core label indicates the vagueness of= our
understanding, even though I think the work is quite accurate for the
scope of what is intended.)

I've be= en thinking about these points in comparison to other successful IETF work = in which I've participated.=C2=A0 The example I keep coming back to is = WEIRDS.=C2=A0 WEIRDS had a basic goal, namely the replacement of WHOIS with= something more modern.=C2=A0 However, it had two very different use cases,= names and numbers, and there was enormous pressure to keep them separate i= n order not to burden one side (which had even developed to prototype imple= menting their proposed solution) with the political baggage of the other.= =C2=A0=C2=A0 There was even an insistence that a "nuclear option"= be included in the charter, granting the co-chairs the right to jettison t= he problematic use case if it seemed to be blocking the other one.=C2=A0 Ne= vertheless, by all accounts I've heard, WEIRDS was a success in that it= did manage to come up with a single solution to both use cases, which is n= ow in the RFC Editor queue.

Back to the DBOUND work: I be= lieve that, even though we again have two primary use cases here, the commu= nity active in this charter's development does satisfy the points you&#= 39;ve addressed, as long as "space" can be interpreted as "s= paces, for which there is some amount of common space".

<= div>Given, in particular, that the highly energetic DMARC community is hung= ry for the output of this working group, I don't have any concerns that= this work will draw sufficient attention once it gets rolling.=C2=A0 Someo= ne else (Jeff, perhaps?) will need to comment on the web community's li= kelihood of participation for that use case.

2.=C2=A0 The DNS community, in particular, has been highly resistant to
substantive changes over the last 25 years.=C2=A0 As such, an effort to add= a
capability of such conceptual note as DBound intends strikes me as
needing particular strong signs of satisfying the above bulleted list.
<= /blockquote>

We do say in the charter that we're con= strained against anything in terms of DNS changes other than registering ne= w RRTYPEs.=C2=A0 The bar has been lower for that of late, as I understand i= t.
=C2=A0
3.=C2=A0 The current drafts are useful documents, but I believe they are quite some distance from garnering community consensus and, even more
importantly, community adoption pressure.

Do initial documents need to have consensus that they're ready to go= , or just that they are reasonable starting points for development?=C2=A0 I= was under the impression that this community agrees that one or both of th= e documents already satisfy the latter criterion.
=C2=A0
4.=C2=A0 A particularly good heuristic for community interest is mailing li= st
activity.=C2=A0 We are not doing well in that regard.
=
I get the impression that this is because the list lately ha= s been dominated by IETF sausage-making rather than actual technological di= scussion.=C2=A0 That doesn't have to be the case, but it might be the a= ssumption some people are making.=C2=A0 By all means, if there's moment= um to do technical development while others are hacking on the charter, peo= ple should feel free to do so.

-MSK
= --047d7ba977a4bcb655050ca8c78b-- From nobody Wed Jan 14 22:02:59 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 DD2AC1B2AFB for ; Wed, 14 Jan 2015 22:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_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 dERTNk8yRMau for ; Wed, 14 Jan 2015 22:02:55 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCBF1B2AFE for ; Wed, 14 Jan 2015 22:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2231; q=dns/txt; s=iport; t=1421301775; x=1422511375; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=55mDs20nJUd72ONaykg+UhB85IgxUjY4ZqSQVTO3ndY=; b=aCjGzjUR10cTZzzK6S64Xx141agnEONoK+F9eaTXvkK8JaOSe7fsfg0V V4Tp4wFlbwdlV8/2sLFYyohwsYQ2Gxcip+dFAi6pIqYQ9gl6p1cGpN6w/ c0HpSc7eySv2SqNvmeaNSG5SDk3d6bvV+f24poE4o3VnEPlkv+g0/U/ki 0=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAKhXt1StJssW/2dsb2JhbABbhzXIfAKBWwEBAQEBfYQNAQEEI1URCw4KCRYLAgIJAwIBAgFFBgEMCAEBEIgYvDSUDgEBAQEBAQEDAQEBAQEBARuQAIJogUEBBJAbgSmGF4Yei2wigjKBPT2CdAEBAQ X-IronPort-AV: E=Sophos;i="5.09,401,1418083200"; d="asc'?scan'208";a="308296188" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Jan 2015 06:02:53 +0000 Received: from [10.61.160.182] ([10.61.160.182]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0F62r8S001143; Thu, 15 Jan 2015 06:02:53 GMT Message-ID: <54B7580C.7030005@cisco.com> Date: Thu, 15 Jan 2015 07:02:52 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Sullivan , dbound@ietf.org References: <20150114022001.23309.qmail@ary.lan> <54B68CA2.6060209@dcrocker.net> <20150114173354.GE62370@mx1.yitter.info> <54B6F453.1070402@dcrocker.net> <20150115024711.GD59044@mx1.yitter.info> In-Reply-To: <20150115024711.GD59044@mx1.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qr48lXaLrASLX6aafNLUjcTcndIj0pPNL" Archived-At: Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 15 Jan 2015 06:02:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qr48lXaLrASLX6aafNLUjcTcndIj0pPNL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andrew & Dave, On 1/15/15 3:47 AM, Andrew Sullivan wrote: >> > broadly, in community terms. (For some reason, I keep thinking that= our >> > using the word 'related' as a core label indicates the vagueness of = our >> > understanding, even though I think the work is quite accurate for th= e >> > scope of what is intended.) > Right. It's a big topic. In my opinion, making it smaller just so > that we can claim it's more concrete would not help. > Right. And coming back to the alternative that Dave posited, I don't think the topic is so broad that we could sustain a research group on it alone.=20 On the other hand, it's lamentable that there is no research group for naming issues. Way back way back, we had the Name Space Research Group (NSRG), but that RG was more focused on evolving the earlier work of Shoch, Clark & Salzter, and attempting to deal with the new and different world of NATs, mobility, and the oncoming instabilities. If there were researchers who wanted to go look at next generation naming approaches, the long term evolution of DNS (or whatever the next thing might be), that would be most welcome (at least from my perspective).=20 But we shouldn't wait on such musings to realize to move forward on dboun= d. Eliot --qr48lXaLrASLX6aafNLUjcTcndIj0pPNL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUt1gMAAoJEIe2a0bZ0nozlTwH/A+25JpkgIvc3EoOJdpDiEfQ RhkD1oK91Rdz6Yf1kYkRU/mkBvbt7oUW99aHGWyI3IPvmKPDef4sTshkovUpSjUY 19Kublvh2ZaHnNDcDpPaRb41NUkcOukU7U6cwfwLOpNtmd/O/py74MNcqPZsdPbE J7bYLKhohih79jwo7Lt14r124e5irh0M7gPlYRrDWmJHEGZdAcTEO+HpPTnoUBTM i1zY99xfuju0uFSpTsMlHJejUPh8MoI59mR9An0OUoBQAMl6r//rPgZnaViK3Nj/ tTTciGs4kxVUiwfjrR7g6eHrusQsUxamJg/r2VeL7fqfF2Uh/dkGxFH+NXlAskM= =tsBP -----END PGP SIGNATURE----- --qr48lXaLrASLX6aafNLUjcTcndIj0pPNL-- From nobody Sat Jan 17 11:26:53 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 6965F1AD05E for ; Sat, 17 Jan 2015 11:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pyDHazx6KUzp for ; Sat, 17 Jan 2015 11:26:50 -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 03B9D1AD04E for ; Sat, 17 Jan 2015 11:26:49 -0800 (PST) Received: (qmail 74865 invoked from network); 17 Jan 2015 19:26:48 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Jan 2015 19:26:48 -0000 Date: 17 Jan 2015 19:26:26 -0000 Message-ID: <20150117192626.19982.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <20150115024711.GD59044@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 17 Jan 2015 19:26:51 -0000 >Our biggest problem seems to be that today, there are two techniques >and they both seem to have corners that don't work well for the other >technique. I think we have a worse problem in that different applications ask very different questions. The only thing they all have in common is that the PSL currently gives the least wrong easily available answer. I still don't see people (not you) appreciating how different these questions are. The cookie application has two names, and asks whether they're under the same management. The DMARC application has one name and asks what's the "highest" name where it can look up a _dmarc record. The CA application has one name, asks for the "highest" name typically to look for WHOIS information. It also asks whether a name is a "private" one that is unlikely to have subdomains delegated to unrelated entities. There are probably other questions, too. Beyond that are management issues, notably whether name owners publish their own info, or it is published by a third party as the PSL is. We've made some progress cataloging the questions, but people are chronically wanting to jump ahead and answer whichever question they're interested in with insufficient consideration of what that does for the other questions, and what assumptions they're making about the management model. R's, John From nobody Tue Jan 20 02:26:26 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 371FD1A87D5; Tue, 13 Jan 2015 15:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 dkDFkG77ar8s; Tue, 13 Jan 2015 15:24:34 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3CF1B2B9D; Tue, 13 Jan 2015 15:24:29 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so5402979lab.3; Tue, 13 Jan 2015 15:24:28 -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=ySuNQ4iQZrcP2UeadqUsFWY4henQ556v6N7oq1TVDbk=; b=irf3gpZ6JrEmYXjkcuYSiuc2cBa8esVFuA5YuX6fj7eOpqi9zoCMoKrUws7neIMy0j R3pbe6imnWIwKAoV6V3gCFjAh1RtEjujyMogti0FH3PRZ5yVIfyI+NZPxh2Xvh9/p7Wm /vDGZiZoSXBj5Jt5uSCpm797N9s//Z+iXir/In2lkxmwSrK2R1y9YXwa5xPsEybMPObj bu7n1jUForVtxw7RVtO1G/JMGCB6H0Z1KX5x+pWJlBkCH8qMcScIX8+ZHlf1JX6k+otl AcRXtmDRmNxvUgt2iD0gyyFhdK/+xsUccb9dqBHeTEkTcUX1u/8uJdblFi12Bct4D13h smGg== MIME-Version: 1.0 X-Received: by 10.112.169.34 with SMTP id ab2mr784756lbc.77.1421191468402; Tue, 13 Jan 2015 15:24:28 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 13 Jan 2015 15:24:28 -0800 (PST) In-Reply-To: References: <20150113225944.4300.64029.idtracker@ietfa.amsl.com> <20150113230502.GL60601@mx1.yitter.info> Date: Tue, 13 Jan 2015 18:24:28 -0500 Message-ID: From: Kathleen Moriarty To: Spencer Dawkins at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 02:26:18 -0800 Cc: The IESG , Andrew Sullivan , dbound@ietf.org Subject: Re: [Dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 13 Jan 2015 23:24:40 -0000 On Tue, Jan 13, 2015 at 6:09 PM, Spencer Dawkins at IETF wrote: > Hi, Andrew, > > On Tue, Jan 13, 2015 at 5:05 PM, Andrew Sullivan > wrote: >> >> On Tue, Jan 13, 2015 at 02:59:44PM -0800, Spencer Dawkins wrote: >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I had one suggestion. This charter is fairly chatty (which is fine), >> > including examples, but after reading it, I wasn't sure whether I'd be >> > able to tell whether ibm.com and ibm.co.uk were related. >> > >> > I think the answer is "yes", but the charter might be clearer if it used >> > an example like that. >> >> Actually, that's one of the questions the WG has to answer, but >> perhaps pointing out that _that_ is a deliverable would be good? > > > That would work for me! Me too, I agree with Spencer's point and question here. Thanks. > > (I'm not sure if I said this clearly - I meant that you'd be able to tell > whether ibm.com and ibm.co.uk were related, or not, not that they obviously > were. Sorry if I was more confused/confusing than usual. > > Spencer >> >> > > -- Best regards, Kathleen From nobody Tue Jan 20 02:26: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 1C2C51A8960; Tue, 6 Jan 2015 22:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 qUe8G2008qVM; Tue, 6 Jan 2015 22:44:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1E81A8749; Tue, 6 Jan 2015 22:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, dbound@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107064449.31560.94139.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 22:44:49 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/iZsOLr_bsXShqBn0OYZTuQGN3uc X-Mailman-Approved-At: Tue, 20 Jan 2015 02:26:18 -0800 Subject: [Dbound] Telechat update notice: X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 06:44:51 -0000 Placed on agenda for telechat - 2015-01-22 ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-dbound/ From nobody Tue Jan 20 02:26:29 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 2A9021A8FD7 for ; Tue, 13 Jan 2015 09:28:01 -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 H1aiqZmHkF9r for ; Tue, 13 Jan 2015 09:27:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E48FA1A902F for ; Tue, 13 Jan 2015 09:27:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dbound@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113172752.20293.61853.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 09:27:52 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 02:26:19 -0800 Subject: [Dbound] State changed: charter-ietf-dbound-00-01 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 17:28:01 -0000 State changed to Internal review. URL: http://datatracker.ietf.org/doc/charter-ietf-dbound/ From nobody Tue Jan 20 20:50: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 4CF751A0354 for ; Tue, 20 Jan 2015 20:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9hR8ZmF46d8g for ; Tue, 20 Jan 2015 20:50:34 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 3B6811A034F for ; Tue, 20 Jan 2015 20:50:34 -0800 (PST) Received: (qmail 29297 invoked by uid 0); 21 Jan 2015 04:50:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 21 Jan 2015 04:50:33 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id iUqS1p0092UhLwi01UqV9D; Tue, 20 Jan 2015 21:50:32 -0700 X-Authority-Analysis: v=2.1 cv=BvIOn+n5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=cmpKiNEfRqcA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=YNv0rlydsVwA:10 a=XQTvw4DszdzChDtK4aAA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=t/dEjVz4CpZp9/Nkxps1I2zWjfk/gZeLBznlC2p5xIQ=; b=pwFeqKyaWWxHTW/GhUXWq5NXmhdTquu4yCIYZybcJ9X7/PNgeZkTUfDC7E8I+5F0YZwCbRxHPKVmA3NmkqEZbNhcW1pN7ILAV086bRxwxHRnZQdNGrYubAzhxFTpxCIo; Received: from [73.202.80.238] (port=45951 helo=[192.168.11.16]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YDnFK-0005wN-4n; Tue, 20 Jan 2015 21:50:26 -0700 Message-ID: <54BF300F.9020107@KingsMountain.com> Date: Tue, 20 Jan 2015 20:50:23 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Levine Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] charter or not? (was: Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 04:50:35 -0000 >AJS wrote.. >>Our biggest problem seems to be that today, there are two techniques >>and they both seem to have corners that don't work well for the other >>technique. > > I think we have a worse problem in that different applications ask > very different questions. The only thing they all have in common is > that the PSL currently gives the least wrong easily available answer. > I still don't see people (not you) appreciating how different these > questions are. > > The cookie application has two names, and asks whether they're > under the same management. > > The DMARC application has one name and asks what's the "highest" > name where it can look up a _dmarc record. > > The CA application has one name, asks for the "highest" name typically > to look for WHOIS information. It also asks whether a name is a > "private" one that is unlikely to have subdomains delegated to > unrelated entities. > > There are probably other questions, too. Beyond that are management > issues, notably whether name owners publish their own info, or it is > published by a third party as the PSL is. > > We've made some progress cataloging the questions, but people are > chronically wanting to jump ahead and answer whichever question > they're interested in with insufficient consideration of what that > does for the other questions, and what assumptions they're making > about the management model. well said, and what that adds up to (seems to me) is we're ready to have a working group and go figure out the rest of the questions and how to design something that answers them. =JeffH From nobody Wed Jan 21 07:34:00 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 C0B871A1ADB for ; Wed, 21 Jan 2015 07:33:58 -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 NEANVPIE5QaI for ; Wed, 21 Jan 2015 07:33:57 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526951A1AD2 for ; Wed, 21 Jan 2015 07:33:57 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so3237634wgh.12 for ; Wed, 21 Jan 2015 07:33:56 -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=XFda0dlCE4og9yOubvt60CYdZs5pz+x/lkF/KNRq+tU=; b=uOdgkr4oM8iUaQHqWJx4k2TyblhhSRb20zsSTiWVZ58HbYcoMgIcwGoAS5KpH+RiR2 CihbznpU44HFBsLM1/q1ClEHd8n6vy6gvwdQwaI4tmHGVucMuqflsUi1TO3oCznncVMg j4MnqCv9VKug5htXGRYuWzUUM2bg04VXiQItMng7E4gPa1MjwWsKmJFAnVbCLMSoNqcQ 7FeZg//qWuD87L/jKmTZUcN90URm6DEFKNlfbGLUEK6SOcTIIRwMjL7xs8T1HHUdE4Qj B1OxdArOKTPQSh+2o30mtgnfPnb4Cbsyj+Or+VnqiYB4pfcbdaHBTs9V5xPdGxVj8UyB Hf6w== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr26561318wjz.89.1421854435592; Wed, 21 Jan 2015 07:33:55 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 21 Jan 2015 07:33:55 -0800 (PST) In-Reply-To: <54BF300F.9020107@KingsMountain.com> References: <54BF300F.9020107@KingsMountain.com> Date: Wed, 21 Jan 2015 07:33:55 -0800 Message-ID: From: "Murray S. Kucherawy" To: "=JeffH" Content-Type: multipart/alternative; boundary=089e0102e4988e5082050d2b4897 Archived-At: Cc: John Levine , "dbound@ietf.org" Subject: Re: [Dbound] charter or not? (was: Spencer Dawkins' No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 15:33:59 -0000 --089e0102e4988e5082050d2b4897 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 20, 2015 at 8:50 PM, =JeffH wrote: > well said, and what that adds up to (seems to me) is we're ready to have a > working group and go figure out the rest of the questions and how to design > something that answers them. > +1. -MSK --089e0102e4988e5082050d2b4897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 20, 2015 at 8:50 PM, =3DJeffH <Je= ff.Hodges@kingsmountain.com> wrote:
well said, a= nd what that adds up to (seems to me) is we're ready to have a working = group and go figure out the rest of the questions and how to design somethi= ng that answers them.

+1.

-MSK <= br>

--089e0102e4988e5082050d2b4897-- From nobody Wed Jan 21 08:08:15 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 50AAC1A1AF4; Wed, 21 Jan 2015 08:08:05 -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 G4PbpXvSVDsr; Wed, 21 Jan 2015 08:07:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB61A1AE2; Wed, 21 Jan 2015 08:07:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121160759.15959.1168.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 08:07:59 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Brian Haberman's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 16:08:06 -0000 Brian Haberman has entered the following ballot position for charter-ietf-dbound-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- When this charter goes for external review, we should ensure that some DNS expertise gets involved in the review. That can be accomplished by asking the Internet Directorate for an explicit review. From nobody Wed Jan 21 08:33: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 CCAE41A1B13; Wed, 21 Jan 2015 08:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 d6KZX7Uv9ijU; Wed, 21 Jan 2015 08:33:03 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35C11A1B11; Wed, 21 Jan 2015 08:33:02 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z11so40320944lbi.6; Wed, 21 Jan 2015 08:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YRXz9BZ0cjiDCqecjwbCMD1K1gZFojhA06LGl/I55Uc=; b=PIjZ0Zcf5WrJ7ExDYG61T1+AafLobL68L2ARO0TbIpXOo29Sbp1ok2IoATK9qEX/3p TLTp/RNW46zNovPoletPWMoYvbZ5AmxvxoT7gsf5EDJOZyKhp9CAhZNVPPv43ZHc/i5P pOWuP3RcGuvpj9wwYQkI6RSO8iGg2W9mMBGM59M922Hg02qcPqsLYOYHxEChj8T01gi6 LdVuZWkC9oVbvFPPYSX0pIoHY2JFm3kjW2uY1gv9Q1Iwt27IMgKUYlg+cEmQJjj8t59I dd4GnBmEuttKf/RMF7kEV0X2f+yuFWOlD0410EXUw9lb9JQU3eJuNswj99jbnidmEmML veSQ== MIME-Version: 1.0 X-Received: by 10.112.25.7 with SMTP id y7mr44843896lbf.94.1421857981188; Wed, 21 Jan 2015 08:33:01 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 21 Jan 2015 08:33:01 -0800 (PST) In-Reply-To: <20150121160759.15959.1168.idtracker@ietfa.amsl.com> References: <20150121160759.15959.1168.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 11:33:01 -0500 X-Google-Sender-Auth: MphCeCRnzupCSzvNmu1lTbLH8rw Message-ID: From: Barry Leiba To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Brian Haberman's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 16:33:04 -0000 > When this charter goes for external review, we should ensure that some > DNS expertise gets involved in the review. That can be accomplished by > asking the Internet Directorate for an explicit review. Is there a list I can post to, as the responsible AD? Or can/should I just delegate that to you, as the AD responsible for the Internet Directorate? b From nobody Wed Jan 21 08:42:50 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 1E0401A1B1F; Wed, 21 Jan 2015 08:42:46 -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 FAXZfsVaAH43; Wed, 21 Jan 2015 08:42:45 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFC61A1B1C; Wed, 21 Jan 2015 08:42:44 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id CE64488125; Wed, 21 Jan 2015 08:42:44 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6C99771C0002; Wed, 21 Jan 2015 08:42:44 -0800 (PST) Message-ID: <54BFD6FD.4010204@innovationslab.net> Date: Wed, 21 Jan 2015 11:42:37 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba References: <20150121160759.15959.1168.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4hulb4mRknELSubfmL7r000Nds8EnMgsc" Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Brian Haberman's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 16:42:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4hulb4mRknELSubfmL7r000Nds8EnMgsc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/21/15 11:33 AM, Barry Leiba wrote: >> When this charter goes for external review, we should ensure that some= >> DNS expertise gets involved in the review. That can be accomplished b= y >> asking the Internet Directorate for an explicit review. >=20 > Is there a list I can post to, as the responsible AD? Or can/should I > just delegate that to you, as the AD responsible for the Internet > Directorate? Either way. The list is int-dir@ietf.org. If you want me to take the token, just let me know. Brian --4hulb4mRknELSubfmL7r000Nds8EnMgsc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUv9cDAAoJEBOZRqCi7goqD6gIAIY1IXCIoiE1EGMncMBH3yKi JHAJaGfiy0Hqtq/wqEaljRoMkKHL3+NVKe+XZG9T8Q3tgA6TIJKcF/HW5pGsLZJ6 8fitT9msjRnyqHuIXQ2wbyqbXjzXAbchZzePovHVtRyFG2vk6WVu+6R9xDMSI4FC K/IB1F5/nSU3hsoJZ4QvUEW8mdbh5M22n+7UuBR3S7XGVIpwXsobooFUpxMOGCuR OmvNVcI7YPPz6UFbc95I4g3Z2G+GApNRtxznITIdgfSccR373XaRqqIZMpiKb9X5 hbmVd1zOfxsflt1dFA6XT3edv0RH0D8PYeCMciB8O5YAtaQuYI//Nuy0Yo7D3cM= =YUrz -----END PGP SIGNATURE----- --4hulb4mRknELSubfmL7r000Nds8EnMgsc-- From nobody Wed Jan 21 10:31: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 F2D201A1BD1; Wed, 21 Jan 2015 10:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 CSs5KEl3paF3; Wed, 21 Jan 2015 10:31:14 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0E41A1BD4; Wed, 21 Jan 2015 10:31:12 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id s18so8601589lam.3; Wed, 21 Jan 2015 10:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x7TJF7a4g2wzSTW0WHKsHPZrUN7/ZLwrpJO798iO15o=; b=Mh4/qHfnJZvWZNfLnUaJSixQE/bXHX8X27QlU1H+x0jNW1jKq65Pdye6K2+V/B88ud kjWKRQyeUjTD88zIC8JkV7xZuTilX3DTSjjWN96GPhtkulfALIXigfLxLvuVCszZ6Jon lcYAjK5gsqlWJiZT9ARuJ+yXXWIMbLLiUhnYQacgeiHJFTJMSlkbHsG7yVxjz+gInZxx IdtvzLmHA+aQ323qXrtKFXHR3hY0SSgt71SEsFOjoolp3p0Y7P38pY4qLbJJW8Y2wsfS JMKpRRahqgyWXrtljh5EyTpz0nH1CFsTghZs3Ag61d0sSaHpFnKnnNXIet9OjF+YDhjr C24Q== MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr46655458lau.42.1421865070566; Wed, 21 Jan 2015 10:31:10 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 21 Jan 2015 10:31:10 -0800 (PST) In-Reply-To: <54BFD6FD.4010204@innovationslab.net> References: <20150121160759.15959.1168.idtracker@ietfa.amsl.com> <54BFD6FD.4010204@innovationslab.net> Date: Wed, 21 Jan 2015 13:31:10 -0500 X-Google-Sender-Auth: eEfFbx4zxe4O6W_6e63OiwDiIy4 Message-ID: From: Barry Leiba To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Brian Haberman's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 18:31:16 -0000 >>> When this charter goes for external review, we should ensure that some >>> DNS expertise gets involved in the review. That can be accomplished by >>> asking the Internet Directorate for an explicit review. >> >> Is there a list I can post to, as the responsible AD? Or can/should I >> just delegate that to you, as the AD responsible for the Internet >> Directorate? > > Either way. The list is int-dir@ietf.org. If you want me to take the > token, just let me know. Thanks. I think the best way is for me to ask the Secretariat to send the new-work notice to the int-dir list as well as to the other channels. I'll do that on the telechat. Barry From nobody Wed Jan 21 12:13: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 504211A87AF; Wed, 21 Jan 2015 12:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 rLsWESKxTKp0; Wed, 21 Jan 2015 12:13:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE9A1A87A7; Wed, 21 Jan 2015 12:13:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 12:13:12 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 20:13:13 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-dbound-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the suggestion of removing the additional information section at the end. Add one sentence to the body of the charter about the PSL if you want, but having that whole section in the charter seems unnecessary. From nobody Wed Jan 21 13:47: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 65B641A006D; Wed, 21 Jan 2015 13:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 UJrUVEGRGQ_e; Wed, 21 Jan 2015 13:47:11 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C32E1A00FC; Wed, 21 Jan 2015 13:47:11 -0800 (PST) Received: from [192.168.1.65] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0LLl436005998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 13:47:07 -0800 Message-ID: <54C01E3D.3030409@dcrocker.net> Date: Wed, 21 Jan 2015 13:46:37 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> In-Reply-To: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Jan 2015 13:47:08 -0800 (PST) Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:47:17 -0000 On 1/21/2015 12:13 PM, Alissa Cooper wrote: > I agree with the suggestion of removing the additional information > section at the end. Add one sentence to the body of the charter about the > PSL if you want, but having that whole section in the charter seems > unnecessary. Unnecessary for the folk who already have enough background in the topic, yes. But this is an unusual and therefore unfamiliar topic. The purpose of the additional text is as an aid at inclusiveness, by virtue of making it easier for a broader base of folk to figure out whether or how this activity might be relevant to them. We tend to write our charters for insiders who already know quite a bit. We ought to make the charter more helpful for others. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 21 14:36:11 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 3E78E1A0053 for ; Wed, 21 Jan 2015 14:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 bXC-KHoTctaq for ; Wed, 21 Jan 2015 14:36:03 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAC41A0095 for ; Wed, 21 Jan 2015 14:36:02 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id z12so21198037lbi.7 for ; Wed, 21 Jan 2015 14:36:01 -0800 (PST) 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=WelYGcLQ6kzk6IVkqHoeJZHj76LOEPI/xpFlFdZT6a4=; b=JjlgOINuC6+Bi9a0KcTaCod4PRPLq3edY6P1AnVbkgWFOHu2Wow4KW0OamEUiU6zHn eTreEl3wxQOoL+UIzB424Zf3DIQr7O9ZysM6jtHPgmjcE3nKMpJOMGpbGS//DLqPjw0A 08v8oWC+0pYB2UUf5dzbpWU6CWrM8a1n/a0luMRPZromJ6X3+aVB5WLW4Ef2/tMNtAV0 pOAIItNKLllcAVBIQM2HaRKPL2sQa+ABvrN/5HEdbdtMZYy8adS24+5Mdl4lYyea7wLr bc/FBiwaXxvNpBw1gBff69uPt/1h7cdtHqGoFkm4YsdJ28qvHukylrwpCHh8yBgPjmx4 o0pQ== X-Gm-Message-State: ALoCoQkBkkPj6xtfeLK0Plr6UMwUC7ZcxPWWAksW7+iDEKVfy7rRdt0PW+TvDQt1XXz+6FsRf2V7 X-Received: by 10.112.43.66 with SMTP id u2mr31702439lbl.35.1421879761372; Wed, 21 Jan 2015 14:36:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.79 with HTTP; Wed, 21 Jan 2015 14:35:31 -0800 (PST) In-Reply-To: <54C01E3D.3030409@dcrocker.net> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> From: Jothan Frakes Date: Wed, 21 Jan 2015 14:35:31 -0800 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11346382171f0f050d312e87 Archived-At: Cc: Alissa Cooper , The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 22:36:06 -0000 --001a11346382171f0f050d312e87 Content-Type: text/plain; charset=UTF-8 There's likely some compromise about PSL as background - although I think Alissa's spot on. PSL really is more of a footnote. Groaning about the PSL, while satisfying to some, seemed to rob the group of cycles and productivity for a fairly protracted period vs focusing on core problem. Jothan Frakes Tel: +1.206-355-0230 On Wed, Jan 21, 2015 at 1:46 PM, Dave Crocker wrote: > On 1/21/2015 12:13 PM, Alissa Cooper wrote: > > I agree with the suggestion of removing the additional information > > section at the end. Add one sentence to the body of the charter about the > > PSL if you want, but having that whole section in the charter seems > > unnecessary. > > > Unnecessary for the folk who already have enough background in the > topic, yes. But this is an unusual and therefore unfamiliar topic. > > The purpose of the additional text is as an aid at inclusiveness, by > virtue of making it easier for a broader base of folk to figure out > whether or how this activity might be relevant to them. > > We tend to write our charters for insiders who already know quite a bit. > We ought to make the charter more helpful for others. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a11346382171f0f050d312e87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's likely some compromise about PSL as background= - although I think Alissa's spot on. PSL really is more of a footnote.=

Groaning about the PSL, while satisfying to some, seemed to rob the= group of cycles and productivity for a fairly protracted period vs focusin= g on core problem.

<= div class=3D"gmail_signature">

Jothan Frakes
Tel: +1= .206-355-0230


On Wed, Jan 21, 2015 at 1:46 PM, Dave Crocke= r <dhc@dcrocker.net> wrote:
On 1/21/2015 12:13 PM, Alissa Cooper wrote:
> I agree with the suggestion of removing the additional information
> section at the end. Add one sentence to the body of the charter about = the
> PSL if you want, but having that whole section in the charter seems > unnecessary.


Unnecessary for the folk who already have enough background in the topic, yes.=C2=A0 But this is an unusual and therefore unfamiliar topic.
The purpose of the additional text is as an aid at inclusiveness, by
virtue of making it easier for a broader base of folk to figure out
whether or how this activity might be relevant to them.

We tend to write our charters for insiders who already know quite a bit. =C2=A0We ought to make the charter more helpful for others.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

--001a11346382171f0f050d312e87-- From nobody Wed Jan 21 14:41:29 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 775431A8989; Wed, 21 Jan 2015 14:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 zbfs9ZVdKtxn; Wed, 21 Jan 2015 14:41:27 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6371A0095; Wed, 21 Jan 2015 14:41:14 -0800 (PST) Received: from [192.168.1.65] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0LMf56A006727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 14:41:08 -0800 Message-ID: <54C02AE8.4010706@dcrocker.net> Date: Wed, 21 Jan 2015 14:40:40 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jothan Frakes , Dave Crocker References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Jan 2015 14:41:09 -0800 (PST) Archived-At: Cc: Alissa Cooper , The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 22:41:28 -0000 On 1/21/2015 2:35 PM, Jothan Frakes wrote: > Groaning about the PSL, while satisfying to some, Which text in the draft charter would you class as 'groaning' and why? Again, the purpose of the extra tutorial material was to aid those lacking sufficient background on the proposed effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 21 15:09: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 2EA431A8A7E for ; Wed, 21 Jan 2015 15:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DvjF17qxJ1aM for ; Wed, 21 Jan 2015 15:09:47 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD9F1A8A78 for ; Wed, 21 Jan 2015 15:09:47 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so43142325lab.8 for ; Wed, 21 Jan 2015 15:09:45 -0800 (PST) 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=xq1XYs9TxVLQGptu88qrjFFXiBbMeZchSnVv/1Yhtoc=; b=JlZAq4W6aaH5yH3bqM449uZzcXG4SIEWarWs5nI5zU+k4nibrkezOWNysNh5WmTi9L LrHUcEbEV3eQd0cjYYmHdlnvxXK3QnW+rg8n+rf4wgaXquOHkiHaCiqCsuuuCmHlSKq7 4qhL5ZhtivXYSNUkD6rlZ602TdrMUWpS9DOgWu1aYGeG11R7eCcQ5olw9CVXCQMs7zyp Th3eXV9VOSieAxio99oSSD4UnoqoWKaeWyVikbxqTXeANlUOWn5z14T0QumKKCHdVS0C QzkQW8ZPt9DtbMWIncShkSjYEF2qne/3s+Nc90BMBn0lhlQX488ouk7zYH4OU0oymtdF baZA== X-Gm-Message-State: ALoCoQkimnZO7Q8HYrH23F/ddYOebVOCOYOvRMxB/6jB/+5Z5QEOvmaJze+EVNNTlH+Z1UhJxIIh X-Received: by 10.112.37.161 with SMTP id z1mr46987893lbj.87.1421881785522; Wed, 21 Jan 2015 15:09:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.79 with HTTP; Wed, 21 Jan 2015 15:09:15 -0800 (PST) In-Reply-To: <54C02AE8.4010706@dcrocker.net> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <54C02AE8.4010706@dcrocker.net> From: Jothan Frakes Date: Wed, 21 Jan 2015 15:09:15 -0800 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11348094bd2d80050d31a607 Archived-At: Cc: Alissa Cooper , The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 23:09:49 -0000 --001a11348094bd2d80050d31a607 Content-Type: text/plain; charset=UTF-8 By my read, Page 3, final paragraph is a fairly good example of where "several inherent limitations" of the PSL are described. Unfortunately, the public suffix list has several inherent limitations. To begin with, it is a list that is separately maintained from the list of DNS delegations. As a result, the data in the public suffix list can diverge from the actual use of the DNS. Second, because its semantics are not the same as those of the DNS, it does not capture unusual features of the DNS that are a consequence of its structure (see [RFC1034 ] for background on that structure). Third, as the size of the root zone grows, keeping the list both accurate and synchronized with the expanding services will become difficult and unreliable. Perhaps most importantly, it puts the power of assertion about the operational policies of a domain outside the control of the operators of that domain, and in the control of a third party possibly unrelated to those operators. Though PSL is very widely used, it seems a missed opportunity to perhaps instead simply abstract things in a sentence or two to define how the use of static lists for DBOUND-esque purpose by developers and integrators is really the issue / problem to be solved. Jothan Frakes Tel: +1.206-355-0230 On Wed, Jan 21, 2015 at 2:40 PM, Dave Crocker wrote: > On 1/21/2015 2:35 PM, Jothan Frakes wrote: > > Groaning about the PSL, while satisfying to some, > > > Which text in the draft charter would you class as 'groaning' and why? > > Again, the purpose of the extra tutorial material was to aid those > lacking sufficient background on the proposed effort. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --001a11348094bd2d80050d31a607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By my read, Page 3, final paragraph is a fairly good examp= le of where "several inherent limitations" of the PSL are describ= ed.


   Unfortunately, the public suffix list has =
several inherent
   limitations.  To begin with, it is a list that is separately
   maintained from the list of DNS delegations.  As a result, the data
   in the public suffix list can diverge from the actual use of the DNS.
   Second, because its semantics are not the same as those of the DNS,
   it does not capture unusual features of the DNS that are a
   consequence of its structure (see [RFC1=
034] for background on that
   structure).  Third, as the size of the root zone grows, keeping the
   list both accurate and synchronized with the expanding services will
   become difficult and unreliable.  Perhaps most importantly, it puts
   the power of assertion about the operational policies of a domain
   outside the control of the operators of that domain, and in the
   control of a third party possibly unrelated to those operators.


Though PSL= is very widely used, it seems a missed opportunity to perhaps instead simp= ly abstract things in a sentence or two to define how the use of static lis= ts for DBOUND-esque purpose by developers and integrators is really the iss= ue / problem to be solved.

Jothan Frakes
Tel: +1.206-355-0230


On Wed, Jan 21, 2015 at 2:40 PM, Dave Crocke= r <dhc@dcrocker.net> wrote:
On 1/21/2015 2:35 PM, Jothan Frakes wrote:
> Groaning about the PSL, while satisfying to some,


Which text in the draft charter would you class as 'groaning'= ; and why?

Again, the purpose of the extra tutorial material was to aid those
lacking sufficient background on the proposed effort.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--001a11348094bd2d80050d31a607-- From nobody Wed Jan 21 15:41: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 3B43F1A1A4D for ; Wed, 21 Jan 2015 15:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 lp3lIPa-2t_h for ; Wed, 21 Jan 2015 15:41:38 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E141A1A3E for ; Wed, 21 Jan 2015 15:41:38 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5BC7F20799 for ; Wed, 21 Jan 2015 18:41:37 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 21 Jan 2015 18:41:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=pg7ruO0yK9yudCzlolJvgAnO8zQ=; b=QE5zKv3yOeokEGbYd6bmj Wkz5qnCWKaOHYqGIqlBJZpNGw+LpUFe7+Yi0APxy99sbRuTFXQZGelMSyh7FwThL gjkD5n+h73IZuqLdImk0KJ+wglckNLL5z8CnWZ+PIkDdkGFN7zQmOsjcVnJwfL3R uYlczHW1SxPgMefDkBxsEs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=pg7ruO0yK9yudCzlolJvgAn O8zQ=; b=FfJFh6BRi7L4OAqMs2+M9g1UBxIhLkNFBX/Y9cRmm/3GB8or3IfMsMc 0k40vrfrBKk2933aLsnOHi6WxD5eXqGyamuaEFqdz1U94jsSlAuBQte6iTuvoKxp QYVI8SAEOFmlqxxEdAd5sSxxzVjLhkh40XJcX27jxjyMFqwKZSN0= X-Sasl-enc: nRlc57MkxeVB6T5koE3VnXxUK3pXcbDQpc9OD3vP2BBO 1421883697 Received: from dhcp-171-68-21-108.cisco.com (unknown [171.68.21.108]) by mail.messagingengine.com (Postfix) with ESMTPA id 78124C0001F; Wed, 21 Jan 2015 18:41:36 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54C01E3D.3030409@dcrocker.net> Date: Wed, 21 Jan 2015 15:41:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IESG , dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 23:41:39 -0000 On Jan 21, 2015, at 1:46 PM, Dave Crocker wrote: > On 1/21/2015 12:13 PM, Alissa Cooper wrote: >> I agree with the suggestion of removing the additional information >> section at the end. Add one sentence to the body of the charter about = the >> PSL if you want, but having that whole section in the charter seems >> unnecessary. >=20 >=20 > Unnecessary for the folk who already have enough background in the > topic, yes. But this is an unusual and therefore unfamiliar topic. >=20 > The purpose of the additional text is as an aid at inclusiveness, by > virtue of making it easier for a broader base of folk to figure out > whether or how this activity might be relevant to them. >=20 > We tend to write our charters for insiders who already know quite a = bit. > We ought to make the charter more helpful for others. I think the main goal of a charter should be to precisely define the = scope of the work of the WG. Extraneous words leave the door open for = scope creep. In this case, I think all of the additional context that a = newcomer would need to understand the work of this proposed WG can fit = into a sentence or two about the PSL. The rest of the text belongs in = the problem statement document. We should prioritize precise scoping = over tutorials in our charters. Alissa >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Wed Jan 21 15:47: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 434CF1A8A8E; Wed, 21 Jan 2015 15:47:11 -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 GzGaCTpRZsKB; Wed, 21 Jan 2015 15:47:09 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A061A00A2; Wed, 21 Jan 2015 15:47:08 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id w7so18494989qcr.10; Wed, 21 Jan 2015 15:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=h1oi25ZvfirJ2ipEufFmxIxK67sbbwNNrZYSXGPz+bo=; b=zjkEGTgRC4CwInqD4//Fv/16QEmtPfOIwAa8RsTMQ5V7gI8ISiW047S5RLfytSalVB o2wrHu7nE+NNP0CFxf2FP/+fMvASr7UDeM9rE+d8dKQSthn6EsPkJjoelqs7K8vDp6RP mlrG6RE7/mFOYh8z7L2+D8JDQa0nQbKdE9r9etbDtn4OiFISIbqYCMK4gwMhM5OWr6AA 2JFlL/4JZeeLKkv5a4xavVcQFWzehoWVknY5s/bNMFjW6Dn/KKBiDZmkuyAnjwlKFDVK SWSDDR7NFki/ionkdLeVDuIO2gJo1jyrjnSjbP3bWCAtJp9atlGyI8ss9adkKnGCs+HQ 3Mmw== X-Received: by 10.224.103.195 with SMTP id l3mr73577027qao.38.1421884027945; Wed, 21 Jan 2015 15:47:07 -0800 (PST) Received: from ?IPv6:2601:6:3a80:77e:2d36:c2b:5295:eff1? ([2601:6:3a80:77e:2d36:c2b:5295:eff1]) by mx.google.com with ESMTPSA id 11sm1635623qgt.41.2015.01.21.15.47.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 15:47:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AB1F6EBA-08C1-47C4-A898-ABD68C7A0DD8" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: Date: Wed, 21 Jan 2015 18:47:13 -0500 Message-Id: <85BC5341-EF08-4880-A677-E2EB6867612C@gmail.com> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <54C02AE8.4010706@dcrocker.net> To: Jothan Frakes X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "dbound@ietf.org" , Alissa Cooper , Dave Crocker , The IESG Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 21 Jan 2015 23:47:11 -0000 --Apple-Mail=_AB1F6EBA-08C1-47C4-A898-ABD68C7A0DD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jothan, On Jan 21, 2015, at 6:09 PM, Jothan Frakes wrote: > By my read, Page 3, final paragraph is a fairly good example of where = "several inherent limitations" of the PSL are described. >=20 >=20 > Unfortunately, the public suffix list has several inherent > limitations. To begin with, it is a list that is separately > maintained from the list of DNS delegations. As a result, the data > in the public suffix list can diverge from the actual use of the = DNS. > Second, because its semantics are not the same as those of the DNS, > it does not capture unusual features of the DNS that are a > consequence of its structure (see [RFC1034] for background on that > structure). Third, as the size of the root zone grows, keeping the > list both accurate and synchronized with the expanding services = will > become difficult and unreliable. Perhaps most importantly, it puts > the power of assertion about the operational policies of a domain > outside the control of the operators of that domain, and in the > control of a third party possibly unrelated to those operators. >=20 >=20 > Though PSL is very widely used, it seems a missed opportunity to = perhaps instead simply abstract things in a sentence or two to define = how the use of static lists for DBOUND-esque purpose by developers and = integrators is really the issue / problem to be solved. In general, I agree with you. But in cases where we're trying to spin up = a new effort to solve a problem people might, at first glance, think is = already solved by existing technology, they will-- and should-- ask = pretty quickly why we think the new effort is worth the pain. (This = happens on a regular basis with DNS, DHCP, and other infrastructure = protocols: "Can't you just use $option we standardized five years ago?") I think what we have in the DBOUND charter, while admittedly awkward, = helps by anticipating the question "Why isn't the PSL close enough to = something like a solution here?" In turn, that gets us to the closely = related question, for a potential participant in the effort, of "Why is = participating in this WG and eventually deploying what it comes up with = likely to be a better use of my time, and solve more of a problem I = actually have, than living with the PSL, what I can come up with on my = own, and other similar technologies?" Thus, I see value in having the explanatory material readily available = to anyone looking at what the WG is trying to do and assessing whether = contributing is worth their while. I don't mind it being in the charter, = but citing the problem statement draft may actually be enough for the = purpose too. best, Suzanne --Apple-Mail=_AB1F6EBA-08C1-47C4-A898-ABD68C7A0DD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jothan,

On Jan 21, 2015, at 6:09 PM, Jothan Frakes = <jothan@jothan.com> = wrote:

By my read, Page 3, final paragraph is a = fairly good example of where "several inherent limitations" of the PSL = are described.


   Unfortunately, the public =
suffix list has several inherent
   limitations.  To begin with, it is a list that is separately
   maintained from the list of DNS delegations.  As a result, the data
   in the public suffix list can diverge from the actual use of the DNS.
   Second, because its semantics are not the same as those of the DNS,
   it does not capture unusual features of the DNS that are a
   consequence of its structure (see [RFC1034] for background on that
   structure).  Third, as the size of the root zone grows, keeping the
   list both accurate and synchronized with the expanding services will
   become difficult and unreliable.  Perhaps most importantly, it puts
   the power of assertion about the operational policies of a domain
   outside the control of the operators of that domain, and in the
   control of a third party possibly unrelated to those =
operators.


Though PSL is very widely used, it seems a = missed opportunity to perhaps instead simply abstract things in a = sentence or two to define how the use of static lists for DBOUND-esque = purpose by developers and integrators is really the issue / problem to = be solved.

In = general, I agree with you. But in cases where we're trying to spin up a = new effort to solve a problem people might, at first glance, think is = already solved by existing technology, they will-- and should-- ask = pretty quickly why we think the new effort is worth the pain. (This = happens on a regular basis with DNS, DHCP, and other infrastructure = protocols: "Can't you just use $option we standardized five years = ago?")

I think what we have in the DBOUND charter, while = admittedly awkward, helps by anticipating the question "Why isn't the = PSL close enough to something like a solution here?" In turn, that gets = us to the closely related question, for a potential participant in the = effort, of "Why is participating in this WG and eventually deploying = what it comes up with likely to be a better use of my time, and solve = more of a problem I actually have, than living with the PSL, what I = can come up with on my own, and other similar = technologies?"

Thus, I see value in having the = explanatory material readily available to anyone looking at what the WG = is trying to do and assessing whether contributing is worth their while. = I don't mind it being in the charter, but citing the problem statement = draft may actually be enough for the purpose = too.


best,
Suzanne=

= --Apple-Mail=_AB1F6EBA-08C1-47C4-A898-ABD68C7A0DD8-- From nobody Wed Jan 21 16:04:00 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 3CCDD1A00A2; Wed, 21 Jan 2015 16:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 ppOh6QPDJNOd; Wed, 21 Jan 2015 16:03:56 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E105A1A0081; Wed, 21 Jan 2015 16:03:55 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id s11so18490406qcv.5; Wed, 21 Jan 2015 16:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0JZCzvJ1KpsPiEZXxVp33ec90cFhpwPl9fcza+hlyf0=; b=qs4v6TI5ckVzuHhk8odLg1Wo0fF4I144JhYjj13LD9BkQjGaO+6a4aHb4oxxOiD1BP q4Oa1TUR5ffoh9dPUgLbJ26ijrvplh/aNYw+aSS9x3e6+QpLKFwJdlE2hOoXxI2lg0xg LRAdqfn/Hh6tlccCwycYCnhyHB7vgzl3JijPKL7ukHED76d/gSSWke3Ol4BybvLVpfHV bw/Lo3WXK+1XfCE0CW3CTPuE3aPewynhzOa2NaxXnP78Wl/r792rAzrJu9yKzy+1FWHE YrwdJkUFDVaktmB9JYrl3Vo44xxUfubVBeDS3L5KbOSXWy2n3avCYQYzPDaW6WiWvLxW C3jw== X-Received: by 10.229.37.136 with SMTP id x8mr73622664qcd.30.1421885035041; Wed, 21 Jan 2015 16:03:55 -0800 (PST) Received: from ?IPv6:2601:6:3a80:77e:2d36:c2b:5295:eff1? ([2601:6:3a80:77e:2d36:c2b:5295:eff1]) by mx.google.com with ESMTPSA id t12sm4823373qam.48.2015.01.21.16.03.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 16:03:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> Date: Wed, 21 Jan 2015 19:04:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B81B183-8B07-486D-B8F6-1B6B5EA2F2A1@gmail.com> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.1510) Archived-At: Cc: dbound@ietf.org, dcrocker@bbiw.net, IESG Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 22 Jan 2015 00:03:58 -0000 On Jan 21, 2015, at 6:41 PM, Alissa Cooper wrote: > On Jan 21, 2015, at 1:46 PM, Dave Crocker wrote: >=20 >> The purpose of the additional text is as an aid at inclusiveness, by >> virtue of making it easier for a broader base of folk to figure out >> whether or how this activity might be relevant to them. >>=20 >> We tend to write our charters for insiders who already know quite a = bit. >> We ought to make the charter more helpful for others. >=20 > I think the main goal of a charter should be to precisely define the = scope of the work of the WG. Extraneous words leave the door open for = scope creep. In this case, I think all of the additional context that a = newcomer would need to understand the work of this proposed WG can fit = into a sentence or two about the PSL. The rest of the text belongs in = the problem statement document. We should prioritize precise scoping = over tutorials in our charters. This is the flip side of what I was trying to say a few minutes ago. The charter was largely drafted before we had the problem statement = (http://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/)= in i-d form. The last couple of paragraphs of Section 2 of the draft is = a start at equivalent text to the supporting material in the draft = charter. I do think defending the choice to charter the WG, and for a participant = to spend time on it, needs to address "why isn't the PSL a solution?" in = some easily referenced form. But I'm increasingly inclined to agree it = doesn't have to be the charter. thanks, Suzanne From nobody Wed Jan 21 16:28:26 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 7B9581A1A88; Wed, 21 Jan 2015 16:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5P7YsOGxGjXG; Wed, 21 Jan 2015 16:28:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2052C1A1A48; Wed, 21 Jan 2015 16:28:24 -0800 (PST) Received: from [10.211.51.212] (gapX16.stanford.edu [171.64.70.50]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0M0SGEW013110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 16:28:20 -0800 Message-ID: <54C04407.5040202@dcrocker.net> Date: Wed, 21 Jan 2015 16:27:51 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , dcrocker@bbiw.net References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> In-Reply-To: <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Jan 2015 16:28:20 -0800 (PST) Archived-At: Cc: IESG , dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 00:28:25 -0000 Alissa, On 1/21/2015 3:41 PM, Alissa Cooper wrote: > I think the main goal of a charter should be to precisely define the > scope of the work of the WG. https://www.ietf.org/wg/ > "WG charters state the scope of work for group, and lay out goals and milestones that show how this work will be completed." and: RFC 2418 - WG Guidelines & Procedures, Section 2.2 Charter starts with text that is similar. These seem in line with your narrow scope for the text. However, when we get down to the RFC discussion of the charter: Description of working group Things get a little more interesting. It includes: By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. and possibly relevant: To facilitate evaluation of the intended work and to provide on- going guidance to the working group, the charter must describe the problem being solved and should discuss objectives and expected impact with respect to: - Architecture - Operations - Security - Network management - Scaling - Transition (where applicable) which suggests that a charter needs to establish its context meaningfully. That is what that extra text is for. > Extraneous words leave the door open for > scope creep. That's an impressively generic assertion. Let me try to match it: The less helpful a charter is for those not already involved in the IETF work, the less inclusive with be working group participation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 21 16:46: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 8972B1A00B6 for ; Wed, 21 Jan 2015 16:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 HZG9JV8KcYg0 for ; Wed, 21 Jan 2015 16:46:14 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268B91A8AE5 for ; Wed, 21 Jan 2015 16:46:13 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id p9so18948459lbv.8 for ; Wed, 21 Jan 2015 16:46:10 -0800 (PST) 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=k23JL2sfmrqCGGR7xvBBkiQiMmn92pckb80jmMD3DaE=; b=YfpTAKoNcz4J/uBIRd+d8tjTdNy8POLh6ZeW0Ifxd6E+9w4wv7bqgv0o7AcLhGzHcX 1HgHUwSOazxXps5F1WZloY+nmy3u6UdMJJLJi9FeoNLqov4V8/H1hiPBUlhIBYMSP8QI 8cQXicPNgF+hsML/L9F99DD3QehE26uQls9ECHkZmNUQwFu0aQowAgYOpSoLwBoD44MD Vk+kIasmyeWLiYNes2IBnlHVlMacTjbePUfLFw1ULQWCBMQnDaO9aHhqqfbm/+DIR6m4 e4+IAgvsOk+eBNfvbN8PiC3YYIJntvwavOcR9zr5NPuaYdA1I+zwMdrOdHxihE4N1hqx +FHA== X-Gm-Message-State: ALoCoQnGXr8D/5qsFzlii+QapGfJYDvVCzjzeoazdskji6QRyGlZAxJNaEpokAhVeCmFsUo/4bgf X-Received: by 10.152.87.106 with SMTP id w10mr18510760laz.41.1421887570764; Wed, 21 Jan 2015 16:46:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.79 with HTTP; Wed, 21 Jan 2015 16:45:40 -0800 (PST) In-Reply-To: <3B81B183-8B07-486D-B8F6-1B6B5EA2F2A1@gmail.com> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> <3B81B183-8B07-486D-B8F6-1B6B5EA2F2A1@gmail.com> From: Jothan Frakes Date: Wed, 21 Jan 2015 16:45:40 -0800 Message-ID: To: Suzanne Woolf Content-Type: multipart/alternative; boundary=001a11c354fa90f6b0050d32ff99 Archived-At: Cc: IESG , Alissa Cooper , Dave Crocker , "dbound@ietf.org" Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 22 Jan 2015 00:46:15 -0000 --001a11c354fa90f6b0050d32ff99 Content-Type: text/plain; charset=UTF-8 I am a volunteer on the PSL. I am not trying to perpetuate its use or defend it here. What I may be poorly articulating is that the issues / problems to solve with DBOUND are being solved with static lists in general. PSL is just one of the more glaring examples of static-lists being maintained outside of the DNS, outside the control of operators by third parties. These exist within the public and private / proprietary realm, though PSL has pretty much become the alpha public list after the IANA TLD List from the Root Zone. The point is that focusing on PSL might not help other static list managers to identify DBOUND as something to watch. Focusing on the problem being things DBOUND is needed for, and how static lists have become a solution space - and how the solution space might need to evolve away from static lists seems a good course forward as opposed to PSL being the problem seems important. Jothan Frakes Tel: +1.206-355-0230 On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Woolf wrote: > > On Jan 21, 2015, at 6:41 PM, Alissa Cooper wrote: > > > On Jan 21, 2015, at 1:46 PM, Dave Crocker wrote: > > > >> The purpose of the additional text is as an aid at inclusiveness, by > >> virtue of making it easier for a broader base of folk to figure out > >> whether or how this activity might be relevant to them. > >> > >> We tend to write our charters for insiders who already know quite a bit. > >> We ought to make the charter more helpful for others. > > > > I think the main goal of a charter should be to precisely define the > scope of the work of the WG. Extraneous words leave the door open for scope > creep. In this case, I think all of the additional context that a newcomer > would need to understand the work of this proposed WG can fit into a > sentence or two about the PSL. The rest of the text belongs in the problem > statement document. We should prioritize precise scoping over tutorials in > our charters. > > This is the flip side of what I was trying to say a few minutes ago. > > The charter was largely drafted before we had the problem statement ( > http://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/) > in i-d form. The last couple of paragraphs of Section 2 of the draft is a > start at equivalent text to the supporting material in the draft charter. > > I do think defending the choice to charter the WG, and for a participant > to spend time on it, needs to address "why isn't the PSL a solution?" in > some easily referenced form. But I'm increasingly inclined to agree it > doesn't have to be the charter. > > > thanks, > Suzanne > > > > > > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a11c354fa90f6b0050d32ff99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a volunteer on the PSL.=C2=A0 I am not trying to perp= etuate its use or defend it here. =C2=A0

What I may be poorly articu= lating is that the issues / problems to solve with DBOUND are being solved = with static lists in general.=C2=A0 PSL is just one of the more glaring exa= mples of static-lists being maintained outside of the DNS, outside the cont= rol of operators by third parties.=C2=A0 These exist within the public and = private / proprietary realm, though PSL has pretty much become the alpha pu= blic list after the IANA TLD List from the Root Zone.=C2=A0 The point is th= at focusing on PSL might not help other static list managers to identify DB= OUND as something to watch.

Focusing on the problem being things DBO= UND is needed for, and how static lists have become a solution space - and = how the solution space might need to evolve away from static lists seems a = good course forward as opposed to PSL being the problem seems important.=C2= =A0



Jothan Frakes
Tel: +1.206-35= 5-0230


On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Woo= lf <suzworldwide@gmail.com> wrote:

On Jan 21, 2015, at 6:41 PM, Alissa Cooper <alissa@cooperw.in> wrote:

> On Jan 21, 2015, at 1:46 PM, Dave Crocker <dhc@dcrocker.net> wrote:
>
>> The purpose of the additional text is as a= n aid at inclusiveness, by
>> virtue of making it easier for a broader base of folk to figure ou= t
>> whether or how this activity might be relevant to them.
>>
>> We tend to write our charters for insiders who already know quite = a bit.
>> We ought to make the charter more helpful for others.
>
> I think the main goal of a charter should be to precisely define the s= cope of the work of the WG. Extraneous words leave the door open for scope = creep. In this case, I think all of the additional context that a newcomer = would need to understand the work of this proposed WG can fit into a senten= ce or two about the PSL. The rest of the text belongs in the problem statem= ent document. We should prioritize precise scoping over tutorials in our ch= arters.

This is the flip side of what I was trying to say a few minutes ago.=

The charter was largely drafted before we had the problem statement (http://datatracker.ietf.org/doc/draft-sullivan-dbound= -problem-statement/) in i-d form. The last couple of paragraphs of Sect= ion 2 of the draft is a start at equivalent text to the supporting material= in the draft charter.

I do think defending the choice to charter the WG, and for a participant to= spend time on it, needs to address "why isn't the PSL a solution?= " in some easily referenced form. But I'm increasingly inclined to= agree it doesn't have to be the charter.


thanks,
Suzanne





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

--001a11c354fa90f6b0050d32ff99-- From nobody Wed Jan 21 16:57:59 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 6FCB11A8AEA for ; Wed, 21 Jan 2015 16:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 J_KTUY94aqwr for ; Wed, 21 Jan 2015 16:57:54 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D7C1A1A75 for ; Wed, 21 Jan 2015 16:57:54 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D77C5207F6 for ; Wed, 21 Jan 2015 19:57:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 21 Jan 2015 19:57:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=/Uyp/Tj1x65DVGknFLzZeD/+5hs=; b=ulOGfUfuw8J9APugLmo4X awUt6zaolZmDL0PG4P9OZb5f92nukkwYfMjtdROcqQeBPWwYGGOuS3OZa13ipFBf emH/RaxDvhvgh9p7c3Pt53usY3e4kxn722vyy8Xu1MfjYPS7UzI7sYQU6J23xx5d nCwi7PSqJCuC29kUlB57bs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=/Uyp/Tj1x65DVGknFLzZeD/ +5hs=; b=A8TKBckl2UlAVMxTXP8ekkWR1Ghj2R4QCmHZiT+LagvsRvkZ2gVwmU6 piQQrAmnokrAzwhAQclClpPSOlZUk7fdEITuMm1g84+J2kjIGhYF4LKlnu644R7g Wl1FOlAcRdq1l9M8BCGBbtV0bcQC8jFnNRX7amL26CGFoMTiDNgw= X-Sasl-enc: LeKIQAnN4hzhYMkjgL6TNliS7VbO5yPOYp6URGwK5nV7 1421888273 Received: from dhcp-171-68-21-108.cisco.com (unknown [171.68.21.108]) by mail.messagingengine.com (Postfix) with ESMTPA id 047F5C0001D; Wed, 21 Jan 2015 19:57:52 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54C04407.5040202@dcrocker.net> Date: Wed, 21 Jan 2015 16:57:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> <54C04407.5040202@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IESG , dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 22 Jan 2015 00:57:56 -0000 Hi Dave, On Jan 21, 2015, at 4:27 PM, Dave Crocker wrote: > Alissa, >=20 > On 1/21/2015 3:41 PM, Alissa Cooper wrote: >> I think the main goal of a charter should be to precisely define the >> scope of the work of the WG.=20 >=20 > https://www.ietf.org/wg/ > >=20 > "WG charters state the scope of work for group, and lay out goals > and milestones that show how this work will be completed." >=20 > and: >=20 > RFC 2418 - WG Guidelines & Procedures, Section 2.2 Charter >=20 > starts with text that is similar. >=20 > These seem in line with your narrow scope for the text. However, when > we get down to the RFC discussion of the charter: >=20 > Description of working group >=20 > Things get a little more interesting. It includes: >=20 > By > reading this section alone, an individual should be able to = decide > whether this group is relevant to their own work. >=20 > and possibly relevant: >=20 > To facilitate evaluation of the intended work and to provide on- > going guidance to the working group, the charter must describe = the > problem being solved and should discuss objectives and expected > impact with respect to: >=20 > - Architecture > - Operations > - Security > - Network management > - Scaling > - Transition (where applicable) >=20 > which suggests that a charter needs to establish its context = meaningfully. >=20 > That is what that extra text is for. The text you quote could easily support either your argument or mine. = Given that I balloted no objection to sending this for external review = (and that Suzanne has suggested a useful path forward), I doubt that = further discussion along these lines is a good use of anyone=92s time. >=20 >=20 >> Extraneous words leave the door open for >> scope creep. >=20 > That's an impressively generic assertion. >=20 > Let me try to match it: >=20 > The less helpful a charter is for those not already involved in = the > IETF work, the less inclusive with be working group participation. I don=92t see any reason why that=92s true, given that we have and make = use of lots of ways of making WG participation inclusive that go far = beyond telling people to go read the charter. Furthermore, if = prospective participants can=92t take the time to click a link and find = the same text in the problem statement, I would worry about their = ability to contribute meaningfully in the WG. Anyway, like I said, we all have more important fish to fry ... Alissa=20 >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Wed Jan 21 17:12:37 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 626FB1A1A75; Wed, 21 Jan 2015 17:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LKP0NJHYUB7O; Wed, 21 Jan 2015 17:12:33 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C631A1A7B; Wed, 21 Jan 2015 17:12:32 -0800 (PST) Received: from [10.211.51.212] (gapX16.stanford.edu [171.64.70.50]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0M1CMw4014346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 17:12:26 -0800 Message-ID: <54C04E5E.3050000@dcrocker.net> Date: Wed, 21 Jan 2015 17:11:58 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , dcrocker@bbiw.net References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> <54C04407.5040202@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 21 Jan 2015 17:12:26 -0800 (PST) Archived-At: Cc: IESG , dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 01:12:35 -0000 On 1/21/2015 4:57 PM, Alissa Cooper wrote: > The text you quote could easily support either your argument or mine. > Given that I balloted no objection to sending this for external > review (and that Suzanne has suggested a useful path forward), I > doubt that further discussion along these lines is a good use of > anyone’s time. Yeah, the latter text I cited is a long way from precisely stating specific requirements. But that's ok; I was more interested in its role as at least providing a basis for what I'm suggesting than in its being definitive for or against. As for your noting that this pertains to a no objection comment, ADs have periodically justified using a Discuss by saying that 'comments' on a non-blocking vote often get ignored. Especially since you are certainly not the first to express concern over the verbosity, I thought it worth pursuing. At a higher level, I think that clarity about the target reader of a charter, and focusing on helping them, is useful... As for Suzanne's suggestion, charter development included discussion about internal vs. external background material. External (eg, citing the I-D) is certainly far better than saying nothing. However Internal significantly reduces the reader's effort at getting 'gist' infomration. Having to go another document doesn't sound onerous, but it's reliably demonstrated to be a meaningful barrier; that means fewer folk who see the charter will get background they need. And just for grins I'll raise a counter-point concerning the verbosity. The intended benefit of it has been explained. As for viewing it as 'too much' verbosity, my question is: What's the damage of retaining that purportedly extra text? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 21 18:35: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 149881A0121; Wed, 21 Jan 2015 18:35:29 -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 dtscVVfQcHyk; Wed, 21 Jan 2015 18:35:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9271A00FA; Wed, 21 Jan 2015 18:35:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122023527.13347.73061.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 18:35:27 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Pete Resnick's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 02:35:29 -0000 Pete Resnick has entered the following ballot position for charter-ietf-dbound-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like others, I'd really rather see the additional background info removed (and indeed, paragraphs 3 and 5 of the main body could also be removed). But if you insist on external review with it, I will not balk. From nobody Wed Jan 21 19:04:38 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 7BEA81A0130; Wed, 21 Jan 2015 19:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 I0KBZ6l9mDk4; Wed, 21 Jan 2015 19:04:25 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D6C1A1A59; Wed, 21 Jan 2015 19:04:20 -0800 (PST) Received: from [172.16.34.6] (unknown [50.189.173.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BA5A68A031; Thu, 22 Jan 2015 03:04:19 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-CA624277-81AC-40B1-A9AB-C50DAA7F40D5 Mime-Version: 1.0 (1.0) From: Andrew Sullivan X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 21 Jan 2015 22:04:21 -0500 Content-Transfer-Encoding: 7bit Message-Id: <40B8124A-DC91-40A9-9072-042B77F4AE00@anvilwalrusden.com> References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> <3B81B183-8B07-486D-B8F6-1B6B5EA2F2A1@gmail.com> To: Jothan Frakes Archived-At: Cc: Suzanne Woolf , "dbound@ietf.org" , Alissa Cooper , IESG , Dave Crocker Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 22 Jan 2015 03:04:27 -0000 --Apple-Mail-CA624277-81AC-40B1-A9AB-C50DAA7F40D5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is an important point. The issue is not PSL as such, but static= lists generally. Perhaps we could make that amendment to the proposed chang= e? Considering its prominence, saying, "=E2=80=A6static lists (like that mo= st prominent one, the PSL)=E2=80=A6" would maybe make the point while yet re= ferring to something familiar.=20 A --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On Jan 21, 2015, at 19:45, Jothan Frakes wrote: >=20 > I am a volunteer on the PSL. I am not trying to perpetuate its use or def= end it here. =20 >=20 > What I may be poorly articulating is that the issues / problems to solve w= ith DBOUND are being solved with static lists in general. PSL is just one o= f the more glaring examples of static-lists being maintained outside of the D= NS, outside the control of operators by third parties. These exist within t= he public and private / proprietary realm, though PSL has pretty much become= the alpha public list after the IANA TLD List from the Root Zone. The poin= t is that focusing on PSL might not help other static list managers to ident= ify DBOUND as something to watch. >=20 > Focusing on the problem being things DBOUND is needed for, and how static l= ists have become a solution space - and how the solution space might need to= evolve away from static lists seems a good course forward as opposed to PSL= being the problem seems important.=20 >=20 >=20 >=20 > Jothan Frakes > Tel: +1.206-355-0230 >=20 >=20 >> On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Woolf w= rote: >>=20 >> On Jan 21, 2015, at 6:41 PM, Alissa Cooper wrote: >>=20 >> > On Jan 21, 2015, at 1:46 PM, Dave Crocker wrote: >> > >> >> The purpose of the additional text is as an aid at inclusiveness, by >> >> virtue of making it easier for a broader base of folk to figure out >> >> whether or how this activity might be relevant to them. >> >> >> >> We tend to write our charters for insiders who already know quite a bi= t. >> >> We ought to make the charter more helpful for others. >> > >> > I think the main goal of a charter should be to precisely define the sc= ope of the work of the WG. Extraneous words leave the door open for scope cr= eep. In this case, I think all of the additional context that a newcomer wou= ld need to understand the work of this proposed WG can fit into a sentence o= r two about the PSL. The rest of the text belongs in the problem statement d= ocument. We should prioritize precise scoping over tutorials in our charters= . >>=20 >> This is the flip side of what I was trying to say a few minutes ago. >>=20 >> The charter was largely drafted before we had the problem statement (http= ://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/) in i-d= form. The last couple of paragraphs of Section 2 of the draft is a start at= equivalent text to the supporting material in the draft charter. >>=20 >> I do think defending the choice to charter the WG, and for a participant t= o spend time on it, needs to address "why isn't the PSL a solution?" in some= easily referenced form. But I'm increasingly inclined to agree it doesn't h= ave to be the charter. >>=20 >>=20 >> thanks, >> Suzanne >>=20 >>=20 >>=20 >>=20 >>=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 --Apple-Mail-CA624277-81AC-40B1-A9AB-C50DAA7F40D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think this is an important point. Th= e issue is not PSL as such, but static lists generally. Perhaps we could mak= e that amendment to the proposed change?  Considering its prominence, s= aying, "=E2=80=A6static lists (like that most prominent one, the PSL)=E2=80=A6= " would maybe make the point while yet referring to something familiar. = ;

A

-- 
Andrew Sullivan = ;
Please excuse my clumbsy thums. 

On Jan= 21, 2015, at 19:45, Jothan Frakes <= jothan@jothan.com> wrote:

I am a volunteer on the PSL.  I am not trying to perp= etuate its use or defend it here.  

What I may be poorly articul= ating is that the issues / problems to solve with DBOUND are being solved wi= th static lists in general.  PSL is just one of the more glaring exampl= es of static-lists being maintained outside of the DNS, outside the control o= f operators by third parties.  These exist within the public and privat= e / proprietary realm, though PSL has pretty much become the alpha public li= st after the IANA TLD List from the Root Zone.  The point is that focus= ing on PSL might not help other static list managers to identify DBOUND as s= omething to watch.

Focusing on the problem being things DBOUND is nee= ded for, and how static lists have become a solution space - and how the sol= ution space might need to evolve away from static lists seems a good course f= orward as opposed to PSL being the problem seems important. 



Jothan Frakes
Tel: +1.206-355-0230


On Wed, Jan 21, 2015 at 4:04 PM, Suzanne Wool= f <suzworldwide@gmail.com> wrote:

On Jan 21, 2015, at 6:41 PM, Alissa Cooper <alissa@cooperw.in> wrote:

> On Jan 21, 2015, at 1:46 PM, Dave Crocker <dhc@dcrocker.net> wrote:
>
>> The purpose of the additional text is as an= aid at inclusiveness, by
>> virtue of making it easier for a broader base of folk to figure out=
>> whether or how this activity might be relevant to them.
>>
>> We tend to write our charters for insiders who already know quite a= bit.
>> We ought to make the charter more helpful for others.
>
> I think the main goal of a charter should be to precisely define the sc= ope of the work of the WG. Extraneous words leave the door open for scope cr= eep. In this case, I think all of the additional context that a newcomer wou= ld need to understand the work of this proposed WG can fit into a sentence o= r two about the PSL. The rest of the text belongs in the problem statement d= ocument. We should prioritize precise scoping over tutorials in our charters= .

This is the flip side of what I was trying to say a few minutes ago.<= br>
The charter was largely drafted before we had the problem statement (http://datatracker.ietf.org/doc/draft-sullivan-dbound-pr= oblem-statement/) in i-d form. The last couple of paragraphs of Section 2= of the draft is a start at equivalent text to the supporting material in th= e draft charter.

I do think defending the choice to charter the WG, and for a participant to s= pend time on it, needs to address "why isn't the PSL a solution?" in some ea= sily referenced form. But I'm increasingly inclined to agree it doesn't have= to be the charter.


thanks,
Suzanne





_______________________________________________
Dbound mailing list
Dbound@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dbound

____________________= ___________________________
Dbound mailing list
Dbound@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/dbound">https://www.ietf.org= /mailman/listinfo/dbound
= --Apple-Mail-CA624277-81AC-40B1-A9AB-C50DAA7F40D5-- From nobody Wed Jan 21 22:48:46 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 4C6B31AC422; Wed, 21 Jan 2015 22:48:44 -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 RYb_3Xp8A20E; Wed, 21 Jan 2015 22:48:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C59061AC41D; Wed, 21 Jan 2015 22:48:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 22:48:42 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 06:48:44 -0000 Richard Barnes has entered the following ballot position for charter-ietf-dbound-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I find this paragraph really troubling: """ The DBOUND working group will develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that different solutions are needed to solve different usage requirements. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. """ That says to me that this group hasn't yet figured out a specific problem that they're solving. The inclusion of the "science fiction" use cases in the problem statement draft doesn't help either. While the PSL-like cases all seem to hang together in terms of setting boundaries along hierarchical lines, the DMARC case envisions "domains that were somehow associated via a policy authority", which sounds like a facility for associating arbitrary things across the DNS. Those two don't sound like part of the same WG to me. I would like to have some discussion on the call of whether this is really properly scoped before we send it forth. From nobody Wed Jan 21 23:05:50 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 40EA71A037C; Wed, 21 Jan 2015 23:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_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 DmTmk6IMYrkW; Wed, 21 Jan 2015 23:05:48 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640881AC42A; Wed, 21 Jan 2015 23:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1535; q=dns/txt; s=iport; t=1421910348; x=1423119948; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=kPdB4Y5qNcdPPqijlB67FEHX1N384vSeDTu9RHhWTaw=; b=eYGYdgMGgA7SC/UpQOBRl9Tv99oSqomHfQQ/0R9PN/v2lNl6JvhT3dqc VVACLm9MO9Ug/mSFIvuz9f/QgbOkoz7noIvkAuM7RaOlzL2nvOnsGqFv4 O8yDXYtiIHHWqjXCv14TdL1Ppg1t52n8nvQPV5F4Wm/ai/jE5GjxamdKx Q=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAASgwFStJssW/2dsb2JhbABbhzTJJQKBYgEBAQEBfYQNAQEEI1UBEAsYCRYLAgIJAwIBAgFFBgEMAQcBAYgovSWUXAEBAQEBAQEBAQEBAQEBAQEBAQEBARePeQeCaIFBAQSQLIEphh6GMot/IoIygT09gnQBAQE X-IronPort-AV: E=Sophos;i="5.09,447,1418083200"; d="asc'?scan'208";a="321465416" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2015 07:05:46 +0000 Received: from [10.61.74.50] (ams3-vpn-dhcp2610.cisco.com [10.61.74.50]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0M75jkg004656; Thu, 22 Jan 2015 07:05:45 GMT Message-ID: <54C0A149.5020609@cisco.com> Date: Thu, 22 Jan 2015 08:05:45 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , dcrocker@bbiw.net References: <20150121201312.5024.69998.idtracker@ietfa.amsl.com> <54C01E3D.3030409@dcrocker.net> <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> In-Reply-To: <1A8DCA36-0320-465B-9BA3-FB4D2564BBC9@cooperw.in> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w3teUMLWwRbR3cfWJhwHIRNsFUVvJAHR6" Archived-At: Cc: IESG , dbound@ietf.org Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 22 Jan 2015 07:05:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w3teUMLWwRbR3cfWJhwHIRNsFUVvJAHR6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 1/22/15 12:41 AM, Alissa Cooper wrote: > I think the main goal of a charter should be to precisely define the > scope of the work of the WG.=20 +1. > Extraneous words leave the door open for scope creep. Well that and confusion. There needs to be a succinct problem statement, a succinct statement as to what is in scope, what is out of scope, and any starting points. But this having been said, there's no real possibility for scope creep here if the front matter (before Background) is correctly written. And so my suggestion is to focus on the front matter. Eliot --w3teUMLWwRbR3cfWJhwHIRNsFUVvJAHR6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUwKFJAAoJEIe2a0bZ0nozbGsIALKPOBNlnC77OtWh1BzzZqqF 86BNR6/qxj8/BvTMk5rG0Q7qsvzO4tUcQeFMPQvCL0NPEDpY0XZd1qfamOTTNgxA gZO2aFTHd8Y0/9xVHxaDOmm4q8l8kDwuraA9YALDbgTKVWmbEWBTs3Bu9LspFCHX do4plNegY4u6emqh8/UCby2dgGXFWhSSXDkbp4J+weB6P7L7q9Kfv57XccDc7QBW CZRXtanR8z4hJWe96P65Z9nJmcEl57SoMwG750DQslph1oGAXJOBzF3GSc5vMmeb s5tMexX04tI8zj4MtlF6PxcwNzGsk45FcZKfLONG/0L5/5DwC2T4KWpOqkv+QM0= =wjAk -----END PGP SIGNATURE----- --w3teUMLWwRbR3cfWJhwHIRNsFUVvJAHR6-- From nobody Wed Jan 21 23:08: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 B9C831AC427; Wed, 21 Jan 2015 23:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_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 cnEPDGueFmmo; Wed, 21 Jan 2015 23:08:43 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616F91A0372; Wed, 21 Jan 2015 23:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2223; q=dns/txt; s=iport; t=1421910522; x=1423120122; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=89fbR3hscaYUB4Snz/nPAByQC3BtIufWoVKVZHaBiSw=; b=dobRUwxdf52qWx/DR34E1Ma03tl83Fep68VODxshCPViLOJ01Wyk+gdA TOpmlZLuKe/PtKY9n7pscHtOpPk23gRRuwuLjyHr79/741Kx/OCvSJkbI AAY2Fw1WYe5AVAhw8sMzylaTlvnzZkzHWuXVv0VM5S653BSoIJIDJFVt0 8=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFADShwFStJssW/2dsb2JhbABbg1hZgwO5eYk8hXECgWIBAQEBAX2EDQEBBCNVARALDgoJFgsCAgkDAgECAUUGAQwBBwEBF4gRDb0flF4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxcRAVAHgmiBQQEEhTuKcYEpT4VPgRQ2gkiCIIt/IoNvPYE9gTcBAQE X-IronPort-AV: E=Sophos;i="5.09,447,1418083200"; d="asc'?scan'208";a="322114216" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2015 07:08:40 +0000 Received: from [10.61.74.50] (ams3-vpn-dhcp2610.cisco.com [10.61.74.50]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0M78e3V016488; Thu, 22 Jan 2015 07:08:40 GMT Message-ID: <54C0A1F8.6090005@cisco.com> Date: Thu, 22 Jan 2015 08:08:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> In-Reply-To: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nfnQ7nax9B7bOxFeUAfci6PfOu0M0V5gD" Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 07:08:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nfnQ7nax9B7bOxFeUAfci6PfOu0M0V5gD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/22/15 7:48 AM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > charter-ietf-dbound-00-01: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-dbound/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I find this paragraph really troubling: > """ > The DBOUND working group will develop a unified solution, if possible, > for determining organizational domain boundaries. However, the working= > group may discover that different solutions are needed to solve > different > usage requirements. Should that happen, the working group will > develop those different solutions, using as many common pieces as it > can. > """ > > That says to me that this group hasn't yet figured out a specific probl= em > that they're solving. Or that this problem manifests itself in different ways depending on the application. Eliot --nfnQ7nax9B7bOxFeUAfci6PfOu0M0V5gD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUwKH5AAoJEIe2a0bZ0nozKL0H/AnAnMZGb7Om2ASmqOPokw/q xDR/CE6yRdrwO/wREjJvHiLCcAZ7LTXRODL3anMo9a21Hc6WgkWo3x8h+vNyDBqE ldmz1B+OnhRa6Cy06JYJnsNHc00pb0pCeRxrofvrgBTkXs6L8y3QoxfOZfXa3qMn C0+AbL4aJuok2w9iC5eX8yqHtuzh4VZoq/y3qxXP0J0jAeRS/M5lCURGCd8ssbrd 1KMh4APTOvXYbJC/vMKbFvqujxAGPV3+/Y2hAW92OlaJgioahLhNCeHNwTu3OHYX k00GfRT/AP7n0JGJEhexTppQ6WtnfOsSvhB5Zj1XZpRDn7sDySQJ0W+bZfEs938= =Jezn -----END PGP SIGNATURE----- --nfnQ7nax9B7bOxFeUAfci6PfOu0M0V5gD-- From nobody Thu Jan 22 05:57:29 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 BCD8A1A1A24 for ; Thu, 22 Jan 2015 05:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 Rdehc9-w8Ss7 for ; Thu, 22 Jan 2015 05:57:20 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 DB4581ACCD8 for ; Thu, 22 Jan 2015 05:57:18 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so1688303lab.12 for ; Thu, 22 Jan 2015 05:57:17 -0800 (PST) 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=dl4ir2f7OLCvH8VM7meqp6Yjzysb9nHvYF4SiIivy3Q=; b=LZE7gG/qrv6RYiUyWkU7lZEENciAlFH+ZjSVfDVxKzq629X35J7YNPSxLEwpKDmZRs VrjLtQ5zukLIlXBMlBSAcNIozqHqxiMP4MsaSsM9JKbXITVl0OBRZwgw9qIblV4V90Hd R08dLCir82y7gyLFSKBtgG81EvDOfbtvYqfhqPeiiDM0McI512crcp4GAfK++xDc72Dz kulKPAB81ZAzcI9fvccpUL/IqiwwNZyRq3wQXDDQDRrXOFbDGnCOlEAqdasHeCy/96yN cBuuJF9yVHb4bnF/+wvfKqi5rdgvJJM3FaQ5a3ZrRa5r4OJHJb6e+CB19hDTdpOEDN8Z 4ICQ== X-Gm-Message-State: ALoCoQltHc9peFuW/Kq6dS5N3b70mke4aQlBugJsAGHQc9wW9xBqn2hDZ9mSxf/UdRNubVBB6rot MIME-Version: 1.0 X-Received: by 10.112.47.135 with SMTP id d7mr1722151lbn.54.1421935037263; Thu, 22 Jan 2015 05:57:17 -0800 (PST) Received: by 10.25.12.215 with HTTP; Thu, 22 Jan 2015 05:57:17 -0800 (PST) In-Reply-To: <54C0A1F8.6090005@cisco.com> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <54C0A1F8.6090005@cisco.com> Date: Thu, 22 Jan 2015 08:57:17 -0500 Message-ID: From: Richard Barnes To: Eliot Lear Content-Type: multipart/alternative; boundary=001a1134d2e6ca432b050d3e0cac Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 13:57:22 -0000 --001a1134d2e6ca432b050d3e0cac Content-Type: text/plain; charset=UTF-8 On Thu, Jan 22, 2015 at 2:08 AM, Eliot Lear wrote: > > On 1/22/15 7:48 AM, Richard Barnes wrote: > > Richard Barnes has entered the following ballot position for > > charter-ietf-dbound-00-01: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/charter-ietf-dbound/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > I find this paragraph really troubling: > > """ > > The DBOUND working group will develop a unified solution, if possible, > > for determining organizational domain boundaries. However, the working > > group may discover that different solutions are needed to solve > > different > > usage requirements. Should that happen, the working group will > > develop those different solutions, using as many common pieces as it > > can. > > """ > > > > That says to me that this group hasn't yet figured out a specific problem > > that they're solving. > > Or that this problem manifests itself in different ways depending on the > application. > In which case, I would hope that the charter would list the applications that it's hoping to address and the solution approaches for each case. --Richard > > Eliot > > > --001a1134d2e6ca432b050d3e0cac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 22, 2015 at 2:08 AM, Eliot Lear <lear@cisco.com> wrote:

On 1/22/15 7:48 AM, Richard Barnes wrote:
> Richard Barnes has entered the following ballot position for
> charter-ietf-dbound-00-01: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-dbound/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> I find this paragraph really troubling:
> """
> The DBOUND working group will develop a unified solution, if possible,=
> for determining organizational domain boundaries.=C2=A0 However, the w= orking
> group may discover that different solutions are needed to solve
> different
> usage requirements.=C2=A0 Should that happen, the working group will > develop those different solutions, using as many common pieces as it > can.
> """
>
> That says to me that this group hasn't yet figured out a specific = problem
> that they're solving.

Or that this problem manifests itself in different ways depending on= the
application.

In which case, I would hop= e that the charter would list the applications that it's hoping to addr= ess and the solution approaches for each case.

--R= ichard

=C2=A0

Eliot



--001a1134d2e6ca432b050d3e0cac-- From nobody Thu Jan 22 07:18:38 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 50C631A8BB4; Thu, 22 Jan 2015 07:18:35 -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 8xwKwaBvt_Gh; Thu, 22 Jan 2015 07:18:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C031A1A11; Thu, 22 Jan 2015 07:18:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122151833.17344.80761.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 07:18:33 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Ted Lemon's No Objection on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 15:18:35 -0000 Ted Lemon has entered the following ballot position for charter-ietf-dbound-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to see the working group start from a narrow scope and recharter if the scope needs widening, as Richard has suggested. From nobody Thu Jan 22 07:37: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 7E0811A1BC5; Thu, 22 Jan 2015 07:37:03 -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 l7PkeA-yN77u; Thu, 22 Jan 2015 07:37:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2761A001C; Thu, 22 Jan 2015 07:37:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122153701.32070.13832.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 07:37:01 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Benoit Claise's Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 15:37:03 -0000 Benoit Claise has entered the following ballot position for charter-ietf-dbound-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- A related problem is known as the "equivalence problem", which is a desire to express that two domains are equivalent, without using existing facilities like CNAME or DNAME that necessitate one of the names being authoritative over the other. "A related problem". Does it mean that the WG is chartered to solve this issue as well? I'm not sure. The following sentence doesn't help me: The DBOUND working group will develop a unified solution, if possible, for determining organizational domain boundaries. From nobody Thu Jan 22 07:37:45 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 73A961A1BC5; Thu, 22 Jan 2015 07:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 lFkc48Vu9_Ba; Thu, 22 Jan 2015 07:37:39 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2531A1AD3; Thu, 22 Jan 2015 07:37:39 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A95868A035; Thu, 22 Jan 2015 15:37:28 +0000 (UTC) Date: Thu, 22 Jan 2015 10:37:30 -0500 From: Andrew Sullivan To: Richard Barnes Message-ID: <20150122153730.GB75671@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 15:37:40 -0000 On Wed, Jan 21, 2015 at 10:48:42PM -0800, Richard Barnes wrote: > That says to me that this group hasn't yet figured out a specific problem > that they're solving. It says that there is a set of problems, all of which are using a common solution that is inadequate to solve _any_ of them, and the WG recognizes that it might be that the real solutions to those different problems might turn out to be different solutions too. It is simply false that WGs have to have exactly one specific problem to be solved; if that were the case, we'd have to close half the WGs in the IETF. The specific problem, then, is the PSL and other static lists of the same sort. If that mechanism is to be replaced, then we need to address the different ways people are using it. And in order to do that, we might end up with more than one mechanism. What is wrong with that? > together in terms of setting boundaries along hierarchical lines, the > DMARC case envisions "domains that were somehow associated via a policy > authority", which sounds like a facility for associating arbitrary things > across the DNS. Those two don't sound like part of the same WG to me. Why not? The assertion that there is a common policy thread that links ancestors to descendents in the DNS hierarchy is in practice wishful thinking. It isn't even the case that you can practically enforce the rules that you make up if you're delegating authority over a subordinate namespace, because to do that you'd have to know what else was going on under there, and you might not even have access to the zone in question. It is true that a superordinate name operator has quite a lot of power over subordinate names in theory (because the superordinate operator can remove the subordinate name or the delegation of the namespace). But the power, while very strong in one dimension, is pathetically weak in the other: you don't have a practical way of knowing. And cross-tree linkages in the DNS are in fact important if we're going to use the DNS as an elementary element of security policies. As more mail operations are outsourced, one needs to be able to apply security policies of different named entities. Corporate mergers and acquitions, as well as name changes, are a fact of life. The inability to tell whether two names are related in any way, whether in an ancestor-descendent relationship or not, is a common issue both down the tree and across it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jan 22 08:03: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 A7C241A87C2; Thu, 22 Jan 2015 08:02:47 -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 Y-ULO-ZSz4vj; Thu, 22 Jan 2015 08:02:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 760BF1A1AC9; Thu, 22 Jan 2015 08:02:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122160245.9661.33575.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 08:02:45 -0800 Archived-At: Cc: dbound@ietf.org Subject: [Dbound] Stephen Farrell's Yes on charter-ietf-dbound-00-01: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:02:48 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-dbound-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It'd be great if this worked out and produced useful stuff. That (getting started) is IMO more important than having the best charter text ever, esp. for the external review stage. I hope we quickly resolve any wording things (even without reaching perfection) and shoot this out. From nobody Thu Jan 22 08:33:11 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 BEBA51A1AC9 for ; Thu, 22 Jan 2015 08:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 xmmTBUR7EN4u for ; Thu, 22 Jan 2015 08:33:03 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 C779E1A1ACA for ; Thu, 22 Jan 2015 08:32:53 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so2597493lab.12 for ; Thu, 22 Jan 2015 08:32:52 -0800 (PST) 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=/iWIOSzFiC1b8oBA7iKBbU9JsMXOmM6gZu/ocp1C3A4=; b=SeHcanJdZO6aJq5cO6rSYz6IbpSD4nC8ZyW5uxXU40yHUYS4PeUX9JWWvhav2LDhb3 lR5+C9JvTu01nT7VJadeAgANwercGE5PtXmetYXwWi5j4gOepz5H5xnfCxLoDNBPI7iI 5yFH7IEM/HKKhrsc3vmr73tmw8oaKDl48Huy4Hn7D862oLyKUVXsJ9D6GH3yiQb6x8WK JYl/omk7FclALJ+skI5EgCYCkhj0nIKdLJAL31YEYjXSbAMZqEfsU3uHj3Ou7FsEFU1C fwq6NErWuQaJWHwXzjzgkC+3PAxt2ubonsnVqB/5n4UgDxPTlsXRZMUay48w/5HtzqbA uKUA== X-Gm-Message-State: ALoCoQlCwzX7vBIVs6FVCjHbTtgKPCZ9FcbG4m4W0yjLcAd8poPdNIDSqoa9ldmZ0KhlC6ufUCyX MIME-Version: 1.0 X-Received: by 10.152.185.72 with SMTP id fa8mr2642952lac.73.1421944372241; Thu, 22 Jan 2015 08:32:52 -0800 (PST) Received: by 10.25.12.215 with HTTP; Thu, 22 Jan 2015 08:32:52 -0800 (PST) In-Reply-To: <20150122153730.GB75671@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> Date: Thu, 22 Jan 2015 11:32:52 -0500 Message-ID: From: Richard Barnes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a113683ea32c379050d4039b0 Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 16:33:04 -0000 --001a113683ea32c379050d4039b0 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 22, 2015 at 10:37 AM, Andrew Sullivan wrote: > On Wed, Jan 21, 2015 at 10:48:42PM -0800, Richard Barnes wrote: > > That says to me that this group hasn't yet figured out a specific problem > > that they're solving. > > It says that there is a set of problems, all of which are using a > common solution that is inadequate to solve _any_ of them, Is this really true? Are people using static lists to encode delegations across the tree? > and the WG > recognizes that it might be that the real solutions to those different > problems might turn out to be different solutions too. It is simply > false that WGs have to have exactly one specific problem to be solved; > if that were the case, we'd have to close half the WGs in the IETF. > I'm not saying there has to be exactly one, but I hope we share the objective of not leaving open ratholes for the WG to fall into. > The specific problem, then, is the PSL and other static lists of the > same sort. If that mechanism is to be replaced, then we need to > address the different ways people are using it. And in order to do > that, we might end up with more than one mechanism. What is wrong > with that? > What are these other static lists? The only thing I see listed in the charter or the problem statement is the PSL. > > together in terms of setting boundaries along hierarchical lines, the > > DMARC case envisions "domains that were somehow associated via a policy > > authority", which sounds like a facility for associating arbitrary things > > across the DNS. Those two don't sound like part of the same WG to me. > > Why not? The assertion that there is a common policy thread that > links ancestors to descendents in the DNS hierarchy is in practice > wishful thinking. It isn't even the case that you can practically > enforce the rules that you make up if you're delegating authority over > a subordinate namespace, because to do that you'd have to know what > else was going on under there, and you might not even have access to > the zone in question. It is true that a superordinate name operator > has quite a lot of power over subordinate names in theory (because the > superordinate operator can remove the subordinate name or the > delegation of the namespace). But the power, while very strong in one > dimension, is pathetically weak in the other: you don't have a > practical way of knowing. > > And cross-tree linkages in the DNS are in fact important if we're > going to use the DNS as an elementary element of security policies. > As more mail operations are outsourced, one needs to be able to apply > security policies of different named entities. Corporate mergers and > acquitions, as well as name changes, are a fact of life. The > inability to tell whether two names are related in any way, whether in > an ancestor-descendent relationship or not, is a common issue both > down the tree and across it. > I think where we disconnect here is that to me, it does seem like there is a Really Big Difference between talking about delegations down the DNS hierarchy and delegations across the tree. When you're talking about the DNS hierarchy, you're adding metadata to an existing delegation system. The relationship is already defined -- parent delegated part of the zone to child. The delegation relationships already exist, and we're just adding a bit of information about the degree of delegation that has occurred. This seems tractable. Talking about arbitrary association of DNS names is a very different question. Now you have to talk about what sorts of relationships you want to encode, which plunges you into a whole world of application-layer semantics. I want to delegate my email to Provider X, but not my web or XMPP services. Do I use this DBOUND thing, or can I only delegate the whole domain with that? This seems like a very deep and attractive rathole. It seems like the PSL / within-the-tree case is well understood and described in the charter, and the only "across-the-tree" stuff is the one hand-wavy paragraph in the problem statement. (Seriously, "somehow associated"?) Can that part simply be excised for now, and maybe brought back in a re-charter when there's a clearer idea of what "somehow associated" means? --Richard > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > --001a113683ea32c379050d4039b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 22, 2015 at 10:37 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On W= ed, Jan 21, 2015 at 10:48:42PM -0800, Richard Barnes wrote:
> That says to me that this group hasn't yet figured out a specific = problem
> that they're solving.

It says that there is a set of problems, all of which are using a common solution that is inadequate to solve _any_ of them,

Is this really true?=C2=A0 Are people using static lists to= encode delegations across the tree?

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> and the WG
recognizes that it might be that the real solutions to those different
problems might turn out to be different solutions too.=C2=A0 It is simply false that WGs have to have exactly one specific problem to be solved;
if that were the case, we'd have to close half the WGs in the IETF.
=

I'm not saying there has to be exactly= one, but I hope we share the objective of not leaving open ratholes for th= e WG to fall into.

=C2=A0
The specific problem, then, is the PSL and other static lists of the
same sort.=C2=A0 If that mechanism is to be replaced, then we need to
address the different ways people are using it.=C2=A0 And in order to do that, we might end up with more than one mechanism.=C2=A0 What is wrong
with that?

What are these other static = lists?=C2=A0 The only thing I see listed in the charter or the problem stat= ement is the PSL. =C2=A0

=C2=A0
> together in terms of setting boundaries along hierarchical lines, the<= br> > DMARC case envisions "domains that were somehow associated via a = policy
> authority", which sounds like a facility for associating arbitrar= y things
> across the DNS.=C2=A0 Those two don't sound like part of the same = WG to me.

Why not?=C2=A0 The assertion that there is a common policy thread th= at
links ancestors to descendents in the DNS hierarchy is in practice
wishful thinking.=C2=A0 It isn't even the case that you can practically=
enforce the rules that you make up if you're delegating authority over<= br> a subordinate namespace, because to do that you'd have to know what
else was going on under there, and you might not even have access to
the zone in question.=C2=A0 It is true that a superordinate name operator has quite a lot of power over subordinate names in theory (because the
superordinate operator can remove the subordinate name or the
delegation of the namespace).=C2=A0 But the power, while very strong in one=
dimension, is pathetically weak in the other: you don't have a
practical way of knowing.

And cross-tree linkages in the DNS are in fact important if we're
going to use the DNS as an elementary element of security policies.
As more mail operations are outsourced, one needs to be able to apply
security policies of different named entities.=C2=A0 Corporate mergers and<= br> acquitions, as well as name changes, are a fact of life.=C2=A0 The
inability to tell whether two names are related in any way, whether in
an ancestor-descendent relationship or not, is a common issue both
down the tree and across it.

I think wh= ere we disconnect here is that to me, it does seem like there is a Really B= ig Difference between talking about delegations down the DNS hierarchy and = delegations across the tree.

When you're talki= ng about the DNS hierarchy, you're adding metadata to an existing deleg= ation system.=C2=A0 The relationship is already defined -- parent delegated= part of the zone to child.=C2=A0 The delegation relationships already exis= t, and we're just adding a bit of information about the degree of deleg= ation that has occurred.=C2=A0 This seems tractable.

Talking about arbitrary association of DNS names is a very different que= stion.=C2=A0 Now you have to talk about what sorts of relationships you wan= t to encode, which plunges you into a whole world of application-layer sema= ntics.=C2=A0 I want to delegate my email to Provider X, but not my web or X= MPP services.=C2=A0 Do I use this DBOUND thing, or can I only delegate the = whole domain with that?=C2=A0 This seems like a very deep and attractive ra= thole.

It seems like the PSL / within-the-tree cas= e is well understood and described in the charter, and the only "acros= s-the-tree" stuff is the one hand-wavy paragraph in the problem statem= ent. =C2=A0(Seriously, "somehow associated"?) =C2=A0Can that part simply be excised fo= r now, and maybe brought back in a re-charter when there's a clearer id= ea of what "somehow ass= ociated" means?

--Richard
= =C2=A0

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

--001a113683ea32c379050d4039b0-- From nobody Thu Jan 22 08:50:26 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 7860B1A1AEA; Thu, 22 Jan 2015 08:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 FgU9l4ExEAak; Thu, 22 Jan 2015 08:50:21 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED85E1A1AE3; Thu, 22 Jan 2015 08:50:20 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8A0DB8A035; Thu, 22 Jan 2015 16:50:19 +0000 (UTC) Date: Thu, 22 Jan 2015 11:50:21 -0500 From: Andrew Sullivan To: Richard Barnes Message-ID: <20150122165021.GH75671@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 16:50:22 -0000 On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: > > > Is this really true? Are people using static lists to encode delegations > across the tree? You can't do delegations across the tree (if we mean the same thing by "delegations"). But DMARC basically waves its hand about this problem, even though it seems to be critical for its operational model. And certainly, CAs spend an awful lot of time (or, anyway, charge one a pile of money and claim to spend time on this effort) developing a picture of how different names are related to one another. > > The specific problem, then, is the PSL and other static lists of the > > same sort. If that mechanism is to be replaced, then we need to > > address the different ways people are using it. And in order to do > > that, we might end up with more than one mechanism. What is wrong > > with that? > > > > What are these other static lists? The only thing I see listed in the > charter or the problem statement is the PSL. Suzanne and Jothan suggested language to fix that, because the PSL is the most visible one but others are maintaining their own. Certainly some CAs have claimed to have their own private lists. > I think where we disconnect here is that to me, it does seem like there is > a Really Big Difference between talking about delegations down the DNS > hierarchy and delegations across the tree. That's because you think this is related to delegations. It's _not_. Dyndns.com makes no delegations, and yet it is a "public suffix" and names beneath it are officially unrelated to one another. Blogspot.com is in the same boat. Hkg1.afilias-nst.info and yyz1.afilias-nst.info are different delegations (there's an SOA at each) and are yet completely within the same administrative control and in fact represent pieces of the very same sub-organization's internal hierarchy. The DNS hierarchy is _accidental_ to this problem; that was the original sin in the Netscape cookies specification. > Talking about arbitrary association of DNS names is a very different > question. Now you have to talk about what sorts of relationships you want > to encode, which plunges you into a whole world of application-layer > semantics. I am claiming, and have been claiming for some time, that the inference from the parent-child relationship is _exactly_ the mistake, and in any case it doesn't help you with things like anti-abuse in messaging because the location in the hierarchy isn't necessarily "parent." So you actually have all this application-layer semantics already, and we're just pretending it's not there. > I want to delegate my email to Provider X, but not my web or > XMPP services. Do I use this DBOUND thing, or can I only delegate the > whole domain with that? This seems like a very deep and attractive rathole. And we had a discssion about it in the past, and will need to talk about it over again, but SRV records and other such friends already give us some hints about the way to proceed. If the goal is to get a sentence in the charter that basically says, "The WG will maximise its use of existing techniques," I'm all on board for it. > It seems like the PSL / within-the-tree case is well understood and Apparently not, or you wouldn't be focussing on delegation. (This very confusion, which is astonishingly resistant to correction, is indeed a serious problem.) > hand-wavy paragraph in the problem statement. (Seriously, "somehow > associated"?) Can that part simply be excised for now, and maybe brought > back in a re-charter when there's a clearer idea of what "somehow > associated" means? I've already removed this notion repeatedly from drafts I've written about this topic, because people keep insisting it's too complicated. Later, it turns out that people realise that they already have the problem, and so it reappears. I'm happy to remove it again, though, if it will make you and others happy. I predict it'll be back, but I'm certainly not devoted to it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jan 22 08:57: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 1FF1E1ACD2C; Thu, 22 Jan 2015 08:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 kqM1QRLM_RXD; Thu, 22 Jan 2015 08:57:32 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F4E1ACD28; Thu, 22 Jan 2015 08:57:31 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0MGvQaF012796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 08:57:29 -0800 Message-ID: <54C12BDC.9010108@dcrocker.net> Date: Thu, 22 Jan 2015 08:57:00 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> In-Reply-To: <20150122165021.GH75671@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Jan 2015 08:57:30 -0800 (PST) Archived-At: Cc: Richard Barnes , The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:57:33 -0000 On 1/22/2015 8:50 AM, Andrew Sullivan wrote: > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: >> >> >> Is this really true? Are people using static lists to encode delegations >> across the tree? > > You can't do delegations across the tree (if we mean the same thing by > "delegations"). But DMARC basically waves its hand about this > problem, even though it seems to be critical for its operational > model. Sorry, but I have no idea what aspect of DMARC you are referring to as being across the tree and critical for its operational model. Please clarify. The only part of DMARC that is normally considered part of this topic is its need to identify the organizational domain, which is strictly and up-the-hierarchy construct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 22 09:15: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 392001ACD60; Thu, 22 Jan 2015 09:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, J_CHICKENPOX_52=0.6] 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 m5SD0LTvFsos; Thu, 22 Jan 2015 09:15:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5631ACD9B; Thu, 22 Jan 2015 09:12:18 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4A1668A035; Thu, 22 Jan 2015 17:12:15 +0000 (UTC) Date: Thu, 22 Jan 2015 12:12:17 -0500 From: Andrew Sullivan To: dcrocker@bbiw.net Message-ID: <20150122171217.GJ75671@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <54C12BDC.9010108@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C12BDC.9010108@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Richard Barnes , The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 22 Jan 2015 17:15:10 -0000 On Thu, Jan 22, 2015 at 08:57:00AM -0800, Dave Crocker wrote: > Sorry, but I have no idea what aspect of DMARC you are referring to as > being across the tree and critical for its operational model. Good, then I'm wrong and we can remove that. The text we have (indeed, the very item Richard is complaining about) came off this mailing list, and Jeff put it in the problem statement draft: DMARC'ss requirement for Identifier Alignment between SPF-authenticated domain, DKIM d=domain, and a message's From: domain could be relaxed to include domains that were somehow associated via a policy authority. This capability would be *very* nice to have at hand. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jan 22 12:26: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 BA1B21A86E9; Thu, 22 Jan 2015 12:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 gu0Qp9PP3ShN; Thu, 22 Jan 2015 12:26:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CCB1A1BED; Thu, 22 Jan 2015 12:26:26 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t0MKQJsI017983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 12:26:23 -0800 Message-ID: <54C15CD2.8000409@dcrocker.net> Date: Thu, 22 Jan 2015 12:25:54 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew Sullivan , dcrocker@bbiw.net References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <54C12BDC.9010108@dcrocker.net> <20150122171217.GJ75671@mx1.yitter.info> In-Reply-To: <20150122171217.GJ75671@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Jan 2015 12:26:24 -0800 (PST) Archived-At: Cc: Richard Barnes , The IESG , dbound@ietf.org Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 20:26:27 -0000 On 1/22/2015 9:12 AM, Andrew Sullivan wrote: > On Thu, Jan 22, 2015 at 08:57:00AM -0800, Dave Crocker wrote: >> Sorry, but I have no idea what aspect of DMARC you are referring to as >> being across the tree and critical for its operational model. > > Good, then I'm wrong and we can remove that. The text we have > (indeed, the very item Richard is complaining about) came off this > mailing list, and Jeff put it in the problem statement draft: > > DMARC'ss requirement for > Identifier Alignment between SPF-authenticated domain, DKIM > d=domain, and a message's From: domain could be relaxed to include > domains that were somehow associated via a policy authority. This > capability would be *very* nice to have at hand. It's entirely reasonable as a component of a think-piece. All sorts of possibilities for dealing with that issue in DMARC have been floated. To my knowledge none has been tested and certainly not at scale. So as for knowing what will work best -- or even work at all, in practical terms -- I believe there is no operational basis for certitude. Hence the assertion "critical for its operational model" is what caused my confusion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 22 19:59: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 65C201A0130 for ; Thu, 22 Jan 2015 19:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Q2qVg39ve0_F for ; Thu, 22 Jan 2015 19:59:43 -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 721D81A0125 for ; Thu, 22 Jan 2015 19:59:43 -0800 (PST) Received: (qmail 2845 invoked from network); 23 Jan 2015 03:59:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2015 03:59:42 -0000 Date: 23 Jan 2015 03:58:57 -0000 Message-ID: <20150123035857.83097.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <40B8124A-DC91-40A9-9072-042B77F4AE00@anvilwalrusden.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Alissa Cooper's No Objection on charter-ietf-dbound-00-01: (with COMMENT) 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, 23 Jan 2015 03:59:44 -0000 In article <40B8124A-DC91-40A9-9072-042B77F4AE00@anvilwalrusden.com> you write: >I think this is an important point. The issue is not PSL as such, but static lists generally. >Perhaps we could make that amendment to the proposed change? Considering its prominence, saying, >"…static lists (like that most prominent one, the PSL)…" would maybe make the point while yet >referring to something familiar. But is the problem with the PSL that it's static, that it's maintained by a third party, that it only has one boundary per tree branch, or what? The answer to all of the questions other than Alyssa's is "if we knew the answer we wouldn't need this WG". R's, John From nobody Fri Jan 23 13:01: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 256A01A7023; Fri, 23 Jan 2015 13:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 UY_kFejOguFz; Fri, 23 Jan 2015 13:01:11 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (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 314811A1B40; Fri, 23 Jan 2015 13:01:11 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ge10so5284649lab.11; Fri, 23 Jan 2015 13:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ld0DVIdKZmODkxYqIDlNIp0lSUuR7RhcfjThzWz4lBQ=; b=Iy7jIm12k2T6x936DbdxcDZ1UDkXbRxSnRiI+Yq6yN7jh98lFsxAl6LXlUBxrGD1Yd QdT0//k9lcuIG5XINpUo6xPXorJz3ULyg9F+rw7KvIr8TfcRaijie0AcOrkg8FR7quJt 2+sfyISvOuUCgnRg1+uL5qN3TfTbmpJfURSJDt8YkQPNYjxYZP9aBfSc4F3miGkeYE/U IWukXvpxs7sTx65jBX5KBsW9M/tgDILRXc+mmqv/y6yIfCBWPVU7OW1dXDWmrKMSJhBE RG0UtMnxjP63P1MLyQ7l4VLscDWeKhZjbOgeBsKbmYei6f60y+sndQO1YPMbuwYxVOod u6CQ== MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr9463508lab.1.1422046869688; Fri, 23 Jan 2015 13:01:09 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Fri, 23 Jan 2015 13:01:09 -0800 (PST) In-Reply-To: <20150122165021.GH75671@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> Date: Fri, 23 Jan 2015 16:01:09 -0500 X-Google-Sender-Auth: nXu-F51z4rogRh6DS6-pWmvNWbI Message-ID: From: Barry Leiba To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Richard Barnes , The IESG , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 23 Jan 2015 21:01:16 -0000 Andrew and Richard: Can you work out some text that maintains the flexibility that the working group needs, while making it clear to Richard what is and isn't in scope, and what the tools are to keep things from ratholing or going off the rails? Barry On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan wrote: > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: >> >> >> Is this really true? Are people using static lists to encode delegations >> across the tree? > > You can't do delegations across the tree (if we mean the same thing by > "delegations"). But DMARC basically waves its hand about this > problem, even though it seems to be critical for its operational > model. And certainly, CAs spend an awful lot of time (or, anyway, > charge one a pile of money and claim to spend time on this effort) > developing a picture of how different names are related to one another. > >> > The specific problem, then, is the PSL and other static lists of the >> > same sort. If that mechanism is to be replaced, then we need to >> > address the different ways people are using it. And in order to do >> > that, we might end up with more than one mechanism. What is wrong >> > with that? >> > >> >> What are these other static lists? The only thing I see listed in the >> charter or the problem statement is the PSL. > > Suzanne and Jothan suggested language to fix that, because the PSL is > the most visible one but others are maintaining their own. Certainly > some CAs have claimed to have their own private lists. > >> I think where we disconnect here is that to me, it does seem like there is >> a Really Big Difference between talking about delegations down the DNS >> hierarchy and delegations across the tree. > > That's because you think this is related to delegations. It's _not_. > Dyndns.com makes no delegations, and yet it is a "public suffix" and > names beneath it are officially unrelated to one another. > Blogspot.com is in the same boat. Hkg1.afilias-nst.info and > yyz1.afilias-nst.info are different delegations (there's an SOA at > each) and are yet completely within the same administrative control > and in fact represent pieces of the very same sub-organization's > internal hierarchy. The DNS hierarchy is _accidental_ to this > problem; that was the original sin in the Netscape cookies > specification. > >> Talking about arbitrary association of DNS names is a very different >> question. Now you have to talk about what sorts of relationships you want >> to encode, which plunges you into a whole world of application-layer >> semantics. > > I am claiming, and have been claiming for some time, that the > inference from the parent-child relationship is _exactly_ the mistake, > and in any case it doesn't help you with things like anti-abuse in > messaging because the location in the hierarchy isn't necessarily > "parent." So you actually have all this application-layer semantics > already, and we're just pretending it's not there. > >> I want to delegate my email to Provider X, but not my web or >> XMPP services. Do I use this DBOUND thing, or can I only delegate the >> whole domain with that? This seems like a very deep and attractive rathole. > > And we had a discssion about it in the past, and will need to talk > about it over again, but SRV records and other such friends already > give us some hints about the way to proceed. > > If the goal is to get a sentence in the charter that basically says, > "The WG will maximise its use of existing techniques," I'm all on > board for it. > >> It seems like the PSL / within-the-tree case is well understood and > > Apparently not, or you wouldn't be focussing on delegation. (This > very confusion, which is astonishingly resistant to correction, is > indeed a serious problem.) > >> hand-wavy paragraph in the problem statement. (Seriously, "somehow >> associated"?) Can that part simply be excised for now, and maybe brought >> back in a re-charter when there's a clearer idea of what "somehow >> associated" means? > > I've already removed this notion repeatedly from drafts I've written > about this topic, because people keep insisting it's too complicated. > Later, it turns out that people realise that they already have the > problem, and so it reappears. I'm happy to remove it again, though, > if it will make you and others happy. I predict it'll be back, but > I'm certainly not devoted to it. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > From nobody Tue Jan 27 08:08:52 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 9AD791A1F01 for ; Tue, 27 Jan 2015 08:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 W41mN6GPmOuJ for ; Tue, 27 Jan 2015 08:08:40 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EF61A8862 for ; Tue, 27 Jan 2015 08:08:23 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id pv20so14050160lab.7 for ; Tue, 27 Jan 2015 08:08:22 -0800 (PST) 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=0w0tWC4iC/jTXL0A82EMu9bYW555E66RFWiHGW44ntI=; b=VbSfoAncMxqjDZYaOnJvPTVqWTznOAmPZefIQixtd5+UYZJmkskC8sk0YSDurwpbGU shfHCEHbLby+IPGoVMM3w+Ux7qCz9mdselZn7pgxgeY7N18D67AptVYLaa3sNsErR1H/ NAiirEQCoENkAxUGXfnfTv4mWbHA0xGzo/WcPeI9r8PI3XfWl0/obiWpBUFshhoOXv4U Dt4InbeSxAnbUhuj97suBj4ScaPQxlhugj2s/ibosVjNyFp+B5ld9mYTGQuNvqxTSx9J Lu7MyPdEgaPxd/4IKGgayJ7gkrKyGjVZ8iXuIXkVo179KPpVQsp1WvrgsxkkENRcjs8t rM+w== X-Gm-Message-State: ALoCoQnX0A7gznLEVkTxDGs+ka0ilvHox17YnCdzNu5dXbTYT+47poP41vDw9v9IQ3Bxcfobbuss MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr2624207lbc.3.1422374901939; Tue, 27 Jan 2015 08:08:21 -0800 (PST) Received: by 10.25.201.86 with HTTP; Tue, 27 Jan 2015 08:08:21 -0800 (PST) In-Reply-To: References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> Date: Tue, 27 Jan 2015 11:08:21 -0500 Message-ID: From: Richard Barnes To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c261fcc495a6050da47685 Archived-At: Cc: Eliot Lear , The IESG , Andrew Sullivan , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 27 Jan 2015 16:08:43 -0000 --001a11c261fcc495a6050da47685 Content-Type: text/plain; charset=UTF-8 Eliot and I had a chat about this during a coffee break at the SEMI workshop. I think I understand the shape of things better now. Would it be accurate to state the goals of the WG in the following way? * Break associations: In cases where one might think two names might seem to be related (i.e., sub-domains), create a way for clients to learn that they are not related. * Make associations: In cases where two names are not otherwise related, create a way for clients to learn that they are related. One additional critical requirement that doesn't seem to me to show up in the charter is that the notion of "related" here is going to need to be defined, and that definition is going to need to be scoped. For example, two domains might be related in the sense of being considered equivalent for purposes of DMARC, but not for purposes of web origin checks. It seems to me that it would be helpful for the goals in the charter to be phrased in the above form. If people think that this aligns well with what the WG is thinking, I would be glad to help craft text. Does that make sense? --Richard On Fri, Jan 23, 2015 at 4:01 PM, Barry Leiba wrote: > Andrew and Richard: Can you work out some text that maintains the > flexibility that the working group needs, while making it clear to > Richard what is and isn't in scope, and what the tools are to keep > things from ratholing or going off the rails? > > Barry > > On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan > wrote: > > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: > >> > >> > >> Is this really true? Are people using static lists to encode > delegations > >> across the tree? > > > > You can't do delegations across the tree (if we mean the same thing by > > "delegations"). But DMARC basically waves its hand about this > > problem, even though it seems to be critical for its operational > > model. And certainly, CAs spend an awful lot of time (or, anyway, > > charge one a pile of money and claim to spend time on this effort) > > developing a picture of how different names are related to one another. > > > >> > The specific problem, then, is the PSL and other static lists of the > >> > same sort. If that mechanism is to be replaced, then we need to > >> > address the different ways people are using it. And in order to do > >> > that, we might end up with more than one mechanism. What is wrong > >> > with that? > >> > > >> > >> What are these other static lists? The only thing I see listed in the > >> charter or the problem statement is the PSL. > > > > Suzanne and Jothan suggested language to fix that, because the PSL is > > the most visible one but others are maintaining their own. Certainly > > some CAs have claimed to have their own private lists. > > > >> I think where we disconnect here is that to me, it does seem like there > is > >> a Really Big Difference between talking about delegations down the DNS > >> hierarchy and delegations across the tree. > > > > That's because you think this is related to delegations. It's _not_. > > Dyndns.com makes no delegations, and yet it is a "public suffix" and > > names beneath it are officially unrelated to one another. > > Blogspot.com is in the same boat. Hkg1.afilias-nst.info and > > yyz1.afilias-nst.info are different delegations (there's an SOA at > > each) and are yet completely within the same administrative control > > and in fact represent pieces of the very same sub-organization's > > internal hierarchy. The DNS hierarchy is _accidental_ to this > > problem; that was the original sin in the Netscape cookies > > specification. > > > >> Talking about arbitrary association of DNS names is a very different > >> question. Now you have to talk about what sorts of relationships you > want > >> to encode, which plunges you into a whole world of application-layer > >> semantics. > > > > I am claiming, and have been claiming for some time, that the > > inference from the parent-child relationship is _exactly_ the mistake, > > and in any case it doesn't help you with things like anti-abuse in > > messaging because the location in the hierarchy isn't necessarily > > "parent." So you actually have all this application-layer semantics > > already, and we're just pretending it's not there. > > > >> I want to delegate my email to Provider X, but not my web or > >> XMPP services. Do I use this DBOUND thing, or can I only delegate the > >> whole domain with that? This seems like a very deep and attractive > rathole. > > > > And we had a discssion about it in the past, and will need to talk > > about it over again, but SRV records and other such friends already > > give us some hints about the way to proceed. > > > > If the goal is to get a sentence in the charter that basically says, > > "The WG will maximise its use of existing techniques," I'm all on > > board for it. > > > >> It seems like the PSL / within-the-tree case is well understood and > > > > Apparently not, or you wouldn't be focussing on delegation. (This > > very confusion, which is astonishingly resistant to correction, is > > indeed a serious problem.) > > > >> hand-wavy paragraph in the problem statement. (Seriously, "somehow > >> associated"?) Can that part simply be excised for now, and maybe > brought > >> back in a re-charter when there's a clearer idea of what "somehow > >> associated" means? > > > > I've already removed this notion repeatedly from drafts I've written > > about this topic, because people keep insisting it's too complicated. > > Later, it turns out that people realise that they already have the > > problem, and so it reappears. I'm happy to remove it again, though, > > if it will make you and others happy. I predict it'll be back, but > > I'm certainly not devoted to it. > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > > --001a11c261fcc495a6050da47685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eliot and I had a chat about this during a coffee break at= the SEMI workshop.=C2=A0 I think I understand the shape of things better n= ow.=C2=A0 Would it be accurate to state the goals of the WG in the followin= g way?

* Break associations: In cases where one might th= ink two names might seem to be related (i.e., sub-domains), create a way fo= r clients to learn that they are not related.
* Make associations= : In cases where two names are not otherwise related, create a way for clie= nts to learn that they are related.

One additional= critical requirement that doesn't seem to me to show up in the charter= is that the notion of "related" here is going to need to be defi= ned, and that definition is going to need to be scoped.=C2=A0 For example, = two domains might be related in the sense of being considered equivalent fo= r purposes of DMARC, but not for purposes of web origin checks.

It seems to me that it would be helpful for the goal= s in the charter to be phrased in the above form.=C2=A0 If people think tha= t this aligns well with what the WG is thinking, I would be glad to help cr= aft text.

Does that make sense?
--Richard



On Fri, Jan 23, 2015 at 4:0= 1 PM, Barry Leiba <barryleiba@computer.org> wrote:
=
Andrew and Richard: Can you work out some te= xt that maintains the
flexibility that the working group needs, while making it clear to
Richard what is and isn't in scope, and what the tools are to keep
things from ratholing or going off the rails?

Barry

On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan
<ajs@anvilwalrusden.com>= ; wrote:
> On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote:
>>
>>
>> Is this really true?=C2=A0 Are people using static lists to encode= delegations
>> across the tree?
>
> You can't do delegations across the tree (if we mean the same thin= g by
> "delegations").=C2=A0 But DMARC basically waves its hand abo= ut this
> problem, even though it seems to be critical for its operational
> model.=C2=A0 And certainly, CAs spend an awful lot of time (or, anyway= ,
> charge one a pile of money and claim to spend time on this effort)
> developing a picture of how different names are related to one another= .
>
>> > The specific problem, then, is the PSL and other static lists= of the
>> > same sort.=C2=A0 If that mechanism is to be replaced, then we= need to
>> > address the different ways people are using it.=C2=A0 And in = order to do
>> > that, we might end up with more than one mechanism.=C2=A0 Wha= t is wrong
>> > with that?
>> >
>>
>> What are these other static lists?=C2=A0 The only thing I see list= ed in the
>> charter or the problem statement is the PSL.
>
> Suzanne and Jothan suggested language to fix that, because the PSL is<= br> > the most visible one but others are maintaining their own.=C2=A0 Certa= inly
> some CAs have claimed to have their own private lists.
>
>> I think where we disconnect here is that to me, it does seem like = there is
>> a Really Big Difference between talking about delegations down the= DNS
>> hierarchy and delegations across the tree.
>
> That's because you think this is related to delegations.=C2=A0 It&= #39;s _not_.
> Dyndns.com makes no delegations, and yet it is a "public suffix&q= uot; and
> names beneath it are officially unrelated to one another.
> Blogspot.com is in the same boat.=C2=A0 Hkg1.afilias-nst.info and
> yyz1.afilia= s-nst.info are different delegations (there's an SOA at
> each) and are yet completely within the same administrative control > and in fact represent pieces of the very same sub-organization's > internal hierarchy.=C2=A0 The DNS hierarchy is _accidental_ to this > problem; that was the original sin in the Netscape cookies
> specification.
>
>> Talking about arbitrary association of DNS names is a very differe= nt
>> question.=C2=A0 Now you have to talk about what sorts of relations= hips you want
>> to encode, which plunges you into a whole world of application-lay= er
>> semantics.
>
> I am claiming, and have been claiming for some time, that the
> inference from the parent-child relationship is _exactly_ the mistake,=
> and in any case it doesn't help you with things like anti-abuse in=
> messaging because the location in the hierarchy isn't necessarily<= br> > "parent."=C2=A0 So you actually have all this application-la= yer semantics
> already, and we're just pretending it's not there.
>
>> I want to delegate my email to Provider X, but not my web or
>> XMPP services.=C2=A0 Do I use this DBOUND thing, or can I only del= egate the
>> whole domain with that?=C2=A0 This seems like a very deep and attr= active rathole.
>
> And we had a discssion about it in the past, and will need to talk
> about it over again, but SRV records and other such friends already > give us some hints about the way to proceed.
>
> If the goal is to get a sentence in the charter that basically says, > "The WG will maximise its use of existing techniques," I'= ;m all on
> board for it.
>
>> It seems like the PSL / within-the-tree case is well understood an= d
>
> Apparently not, or you wouldn't be focussing on delegation.=C2=A0 = (This
> very confusion, which is astonishingly resistant to correction, is
> indeed a serious problem.)
>
>> hand-wavy paragraph in the problem statement.=C2=A0 (Seriously, &q= uot;somehow
>> associated"?)=C2=A0 Can that part simply be excised for now, = and maybe brought
>> back in a re-charter when there's a clearer idea of what "= ;somehow
>> associated" means?
>
> I've already removed this notion repeatedly from drafts I've w= ritten
> about this topic, because people keep insisting it's too complicat= ed.
> Later, it turns out that people realise that they already have the
> problem, and so it reappears.=C2=A0 I'm happy to remove it again, = though,
> if it will make you and others happy.=C2=A0 I predict it'll be bac= k, but
> I'm certainly not devoted to it.
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com >

--001a11c261fcc495a6050da47685-- From nobody Tue Jan 27 08:27: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 1A1EF1A8886; Tue, 27 Jan 2015 08:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 uKUPRk_7WDHa; Tue, 27 Jan 2015 08:27:27 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2809B1A885A; Tue, 27 Jan 2015 08:27:26 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3A0808A031; Tue, 27 Jan 2015 16:27:25 +0000 (UTC) Date: Tue, 27 Jan 2015 11:27:22 -0500 From: Andrew Sullivan To: Richard Barnes Message-ID: <20150127162722.GE1428@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Barry Leiba , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 27 Jan 2015 16:27:29 -0000 Hi, I rather like this way of stating things; thanks. I think in addition, the WG has more or less determined that the first relationship it will work on is "public suffix list", and the problem that you've been finding frustrating is exactly that it turns out the PSL is used for more than one thing, and we simply are not certain whether they are all one type of relationship (but we suspect pretty strongly that they're not -- see John Levine's quite clear account of this). What I can't tell from your note is whether you require the charter to scope these notions of "related" or whether you think it would be ok for the WG to form and have as its first item sorting out different scopes. A On Tue, Jan 27, 2015 at 11:08:21AM -0500, Richard Barnes wrote: > Eliot and I had a chat about this during a coffee break at the SEMI > workshop. I think I understand the shape of things better now. Would it > be accurate to state the goals of the WG in the following way? > > * Break associations: In cases where one might think two names might seem > to be related (i.e., sub-domains), create a way for clients to learn that > they are not related. > * Make associations: In cases where two names are not otherwise related, > create a way for clients to learn that they are related. > > One additional critical requirement that doesn't seem to me to show up in > the charter is that the notion of "related" here is going to need to be > defined, and that definition is going to need to be scoped. For example, > two domains might be related in the sense of being considered equivalent > for purposes of DMARC, but not for purposes of web origin checks. > > It seems to me that it would be helpful for the goals in the charter to be > phrased in the above form. If people think that this aligns well with what > the WG is thinking, I would be glad to help craft text. > > Does that make sense? > > --Richard > > > > On Fri, Jan 23, 2015 at 4:01 PM, Barry Leiba > wrote: > > > Andrew and Richard: Can you work out some text that maintains the > > flexibility that the working group needs, while making it clear to > > Richard what is and isn't in scope, and what the tools are to keep > > things from ratholing or going off the rails? > > > > Barry > > > > On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan > > wrote: > > > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: > > >> > > >> > > >> Is this really true? Are people using static lists to encode > > delegations > > >> across the tree? > > > > > > You can't do delegations across the tree (if we mean the same thing by > > > "delegations"). But DMARC basically waves its hand about this > > > problem, even though it seems to be critical for its operational > > > model. And certainly, CAs spend an awful lot of time (or, anyway, > > > charge one a pile of money and claim to spend time on this effort) > > > developing a picture of how different names are related to one another. > > > > > >> > The specific problem, then, is the PSL and other static lists of the > > >> > same sort. If that mechanism is to be replaced, then we need to > > >> > address the different ways people are using it. And in order to do > > >> > that, we might end up with more than one mechanism. What is wrong > > >> > with that? > > >> > > > >> > > >> What are these other static lists? The only thing I see listed in the > > >> charter or the problem statement is the PSL. > > > > > > Suzanne and Jothan suggested language to fix that, because the PSL is > > > the most visible one but others are maintaining their own. Certainly > > > some CAs have claimed to have their own private lists. > > > > > >> I think where we disconnect here is that to me, it does seem like there > > is > > >> a Really Big Difference between talking about delegations down the DNS > > >> hierarchy and delegations across the tree. > > > > > > That's because you think this is related to delegations. It's _not_. > > > Dyndns.com makes no delegations, and yet it is a "public suffix" and > > > names beneath it are officially unrelated to one another. > > > Blogspot.com is in the same boat. Hkg1.afilias-nst.info and > > > yyz1.afilias-nst.info are different delegations (there's an SOA at > > > each) and are yet completely within the same administrative control > > > and in fact represent pieces of the very same sub-organization's > > > internal hierarchy. The DNS hierarchy is _accidental_ to this > > > problem; that was the original sin in the Netscape cookies > > > specification. > > > > > >> Talking about arbitrary association of DNS names is a very different > > >> question. Now you have to talk about what sorts of relationships you > > want > > >> to encode, which plunges you into a whole world of application-layer > > >> semantics. > > > > > > I am claiming, and have been claiming for some time, that the > > > inference from the parent-child relationship is _exactly_ the mistake, > > > and in any case it doesn't help you with things like anti-abuse in > > > messaging because the location in the hierarchy isn't necessarily > > > "parent." So you actually have all this application-layer semantics > > > already, and we're just pretending it's not there. > > > > > >> I want to delegate my email to Provider X, but not my web or > > >> XMPP services. Do I use this DBOUND thing, or can I only delegate the > > >> whole domain with that? This seems like a very deep and attractive > > rathole. > > > > > > And we had a discssion about it in the past, and will need to talk > > > about it over again, but SRV records and other such friends already > > > give us some hints about the way to proceed. > > > > > > If the goal is to get a sentence in the charter that basically says, > > > "The WG will maximise its use of existing techniques," I'm all on > > > board for it. > > > > > >> It seems like the PSL / within-the-tree case is well understood and > > > > > > Apparently not, or you wouldn't be focussing on delegation. (This > > > very confusion, which is astonishingly resistant to correction, is > > > indeed a serious problem.) > > > > > >> hand-wavy paragraph in the problem statement. (Seriously, "somehow > > >> associated"?) Can that part simply be excised for now, and maybe > > brought > > >> back in a re-charter when there's a clearer idea of what "somehow > > >> associated" means? > > > > > > I've already removed this notion repeatedly from drafts I've written > > > about this topic, because people keep insisting it's too complicated. > > > Later, it turns out that people realise that they already have the > > > problem, and so it reappears. I'm happy to remove it again, though, > > > if it will make you and others happy. I predict it'll be back, but > > > I'm certainly not devoted to it. > > > > > > A > > > > > > -- > > > Andrew Sullivan > > > ajs@anvilwalrusden.com > > > > > -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jan 27 08:38:26 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 6C1321A88F8 for ; Tue, 27 Jan 2015 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 PD22i1_72eoY for ; Tue, 27 Jan 2015 08:38:06 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF901A8870 for ; Tue, 27 Jan 2015 08:30:08 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so14279603lam.5 for ; Tue, 27 Jan 2015 08:30:07 -0800 (PST) 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=OdaRNn9I9JbESdS8zq+ceZJgU15CJq0jU1ZGkkZ4nmY=; b=YY41Tn27Y6ufQTvrnWJAEMx2wVitRNhZK4HzLt5g9lt4YXLXmlY0o5iJYXwVFoc2F7 EP3NXhc6hdPk9k2w5Kf02XDqVtr+Gtjw/86eP25YjKRBkwPhvuGjQHAxaLcljUzrn8RE U/xWkk1aeQObVuHTiMVeWafEmaK5uK7Iflx5wpMXULuHVZJi+sUdWU1g4PQbHpRiCuJV AZas1qlAxohZ5OgWvzfC58IAssOxnNwWxtNOFEd9LrFBVO+MAylWhth9cHWS7x7N9n41 5gEUo59pWFHVtgZ7YMUvfi2/gUzoCT5YXgvSum2ZUkmLO3SpRl1cdoc61ZlzTw/fzn4r UtlA== X-Gm-Message-State: ALoCoQnCebe/mFguWVFipEiLyTmOZdTvsg6h5UfOVooX3gQ94pZV0mxGsyXc2zFCskW5SVQ/VBRK MIME-Version: 1.0 X-Received: by 10.152.7.7 with SMTP id f7mr2568004laa.27.1422376207239; Tue, 27 Jan 2015 08:30:07 -0800 (PST) Received: by 10.25.201.86 with HTTP; Tue, 27 Jan 2015 08:30:07 -0800 (PST) In-Reply-To: <20150127162722.GE1428@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> Date: Tue, 27 Jan 2015 11:30:07 -0500 Message-ID: From: Richard Barnes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2870a91e14b050da4c463 Archived-At: Cc: Barry Leiba , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 27 Jan 2015 16:38:19 -0000 --001a11c2870a91e14b050da4c463 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 27, 2015 at 11:27 AM, Andrew Sullivan wrote: > Hi, > > I rather like this way of stating things; thanks. I think in > addition, the WG has more or less determined that the first > relationship it will work on is "public suffix list", and the problem > that you've been finding frustrating is exactly that it turns out the > PSL is used for more than one thing, and we simply are not certain > whether they are all one type of relationship (but we suspect pretty > strongly that they're not -- see John Levine's quite clear account of > this). > > What I can't tell from your note is whether you require the charter to > scope these notions of "related" or whether you think it would be ok > for the WG to form and have as its first item sorting out different > scopes. > I think it would be sufficient to just say, that "related" is not a unitary concept, and that there will be different flavors of relationship. --Richard > > A > > On Tue, Jan 27, 2015 at 11:08:21AM -0500, Richard Barnes wrote: > > Eliot and I had a chat about this during a coffee break at the SEMI > > workshop. I think I understand the shape of things better now. Would it > > be accurate to state the goals of the WG in the following way? > > > > * Break associations: In cases where one might think two names might seem > > to be related (i.e., sub-domains), create a way for clients to learn that > > they are not related. > > * Make associations: In cases where two names are not otherwise related, > > create a way for clients to learn that they are related. > > > > One additional critical requirement that doesn't seem to me to show up in > > the charter is that the notion of "related" here is going to need to be > > defined, and that definition is going to need to be scoped. For example, > > two domains might be related in the sense of being considered equivalent > > for purposes of DMARC, but not for purposes of web origin checks. > > > > It seems to me that it would be helpful for the goals in the charter to > be > > phrased in the above form. If people think that this aligns well with > what > > the WG is thinking, I would be glad to help craft text. > > > > Does that make sense? > > > > --Richard > > > > > > > > On Fri, Jan 23, 2015 at 4:01 PM, Barry Leiba > > wrote: > > > > > Andrew and Richard: Can you work out some text that maintains the > > > flexibility that the working group needs, while making it clear to > > > Richard what is and isn't in scope, and what the tools are to keep > > > things from ratholing or going off the rails? > > > > > > Barry > > > > > > On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan > > > wrote: > > > > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wrote: > > > >> > > > >> > > > >> Is this really true? Are people using static lists to encode > > > delegations > > > >> across the tree? > > > > > > > > You can't do delegations across the tree (if we mean the same thing > by > > > > "delegations"). But DMARC basically waves its hand about this > > > > problem, even though it seems to be critical for its operational > > > > model. And certainly, CAs spend an awful lot of time (or, anyway, > > > > charge one a pile of money and claim to spend time on this effort) > > > > developing a picture of how different names are related to one > another. > > > > > > > >> > The specific problem, then, is the PSL and other static lists of > the > > > >> > same sort. If that mechanism is to be replaced, then we need to > > > >> > address the different ways people are using it. And in order to > do > > > >> > that, we might end up with more than one mechanism. What is wrong > > > >> > with that? > > > >> > > > > >> > > > >> What are these other static lists? The only thing I see listed in > the > > > >> charter or the problem statement is the PSL. > > > > > > > > Suzanne and Jothan suggested language to fix that, because the PSL is > > > > the most visible one but others are maintaining their own. Certainly > > > > some CAs have claimed to have their own private lists. > > > > > > > >> I think where we disconnect here is that to me, it does seem like > there > > > is > > > >> a Really Big Difference between talking about delegations down the > DNS > > > >> hierarchy and delegations across the tree. > > > > > > > > That's because you think this is related to delegations. It's _not_. > > > > Dyndns.com makes no delegations, and yet it is a "public suffix" and > > > > names beneath it are officially unrelated to one another. > > > > Blogspot.com is in the same boat. Hkg1.afilias-nst.info and > > > > yyz1.afilias-nst.info are different delegations (there's an SOA at > > > > each) and are yet completely within the same administrative control > > > > and in fact represent pieces of the very same sub-organization's > > > > internal hierarchy. The DNS hierarchy is _accidental_ to this > > > > problem; that was the original sin in the Netscape cookies > > > > specification. > > > > > > > >> Talking about arbitrary association of DNS names is a very different > > > >> question. Now you have to talk about what sorts of relationships > you > > > want > > > >> to encode, which plunges you into a whole world of application-layer > > > >> semantics. > > > > > > > > I am claiming, and have been claiming for some time, that the > > > > inference from the parent-child relationship is _exactly_ the > mistake, > > > > and in any case it doesn't help you with things like anti-abuse in > > > > messaging because the location in the hierarchy isn't necessarily > > > > "parent." So you actually have all this application-layer semantics > > > > already, and we're just pretending it's not there. > > > > > > > >> I want to delegate my email to Provider X, but not my web or > > > >> XMPP services. Do I use this DBOUND thing, or can I only delegate > the > > > >> whole domain with that? This seems like a very deep and attractive > > > rathole. > > > > > > > > And we had a discssion about it in the past, and will need to talk > > > > about it over again, but SRV records and other such friends already > > > > give us some hints about the way to proceed. > > > > > > > > If the goal is to get a sentence in the charter that basically says, > > > > "The WG will maximise its use of existing techniques," I'm all on > > > > board for it. > > > > > > > >> It seems like the PSL / within-the-tree case is well understood and > > > > > > > > Apparently not, or you wouldn't be focussing on delegation. (This > > > > very confusion, which is astonishingly resistant to correction, is > > > > indeed a serious problem.) > > > > > > > >> hand-wavy paragraph in the problem statement. (Seriously, "somehow > > > >> associated"?) Can that part simply be excised for now, and maybe > > > brought > > > >> back in a re-charter when there's a clearer idea of what "somehow > > > >> associated" means? > > > > > > > > I've already removed this notion repeatedly from drafts I've written > > > > about this topic, because people keep insisting it's too complicated. > > > > Later, it turns out that people realise that they already have the > > > > problem, and so it reappears. I'm happy to remove it again, though, > > > > if it will make you and others happy. I predict it'll be back, but > > > > I'm certainly not devoted to it. > > > > > > > > A > > > > > > > > -- > > > > Andrew Sullivan > > > > ajs@anvilwalrusden.com > > > > > > > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > --001a11c2870a91e14b050da4c463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 27, 2015 at 11:27 AM, Andrew Sullivan <= ;ajs@anvilwalru= sden.com> wrote:
Hi,

I rather like this way of stating things; thanks.=C2=A0 I think in
addition, the WG has more or less determined that the first
relationship it will work on is "public suffix list", and the pro= blem
that you've been finding frustrating is exactly that it turns out the PSL is used for more than one thing, and we simply are not certain
whether they are all one type of relationship (but we suspect pretty
strongly that they're not -- see John Levine's quite clear account = of
this).

What I can't tell from your note is whether you require the charter to<= br> scope these notions of "related" or whether you think it would be= ok
for the WG to form and have as its first item sorting out different
scopes.

I think it would be sufficient = to just say, that "related" is not a unitary concept, and that th= ere will be different flavors of relationship.

--R= ichard

=C2=A0

A

On Tue, Jan 27, 2015 at 11:08:21AM -0500, Richard Barnes wrote:
> Eliot and I had a chat about this during a coffee break at the SEMI > workshop.=C2=A0 I think I understand the shape of things better now.= =C2=A0 Would it
> be accurate to state the goals of the WG in the following way?
>
> * Break associations: In cases where one might think two names might s= eem
> to be related (i.e., sub-domains), create a way for clients to learn t= hat
> they are not related.
> * Make associations: In cases where two names are not otherwise relate= d,
> create a way for clients to learn that they are related.
>
> One additional critical requirement that doesn't seem to me to sho= w up in
> the charter is that the notion of "related" here is going to= need to be
> defined, and that definition is going to need to be scoped.=C2=A0 For = example,
> two domains might be related in the sense of being considered equivale= nt
> for purposes of DMARC, but not for purposes of web origin checks.
>
> It seems to me that it would be helpful for the goals in the charter t= o be
> phrased in the above form.=C2=A0 If people think that this aligns well= with what
> the WG is thinking, I would be glad to help craft text.
>
> Does that make sense?
>
> --Richard
>
>
>
> On Fri, Jan 23, 2015 at 4:01 PM, Barry Leiba <barryleiba@computer.org>
> wrote:
>
> > Andrew and Richard: Can you work out some text that maintains the=
> > flexibility that the working group needs, while making it clear t= o
> > Richard what is and isn't in scope, and what the tools are to= keep
> > things from ratholing or going off the rails?
> >
> > Barry
> >
> > On Thu, Jan 22, 2015 at 11:50 AM, Andrew Sullivan
> > <ajs@anvilwalrusden.= com> wrote:
> > > On Thu, Jan 22, 2015 at 11:32:52AM -0500, Richard Barnes wro= te:
> > >>
> > >>
> > >> Is this really true?=C2=A0 Are people using static lists= to encode
> > delegations
> > >> across the tree?
> > >
> > > You can't do delegations across the tree (if we mean the= same thing by
> > > "delegations").=C2=A0 But DMARC basically waves it= s hand about this
> > > problem, even though it seems to be critical for its operati= onal
> > > model.=C2=A0 And certainly, CAs spend an awful lot of time (= or, anyway,
> > > charge one a pile of money and claim to spend time on this e= ffort)
> > > developing a picture of how different names are related to o= ne another.
> > >
> > >> > The specific problem, then, is the PSL and other st= atic lists of the
> > >> > same sort.=C2=A0 If that mechanism is to be replace= d, then we need to
> > >> > address the different ways people are using it.=C2= =A0 And in order to do
> > >> > that, we might end up with more than one mechanism.= =C2=A0 What is wrong
> > >> > with that?
> > >> >
> > >>
> > >> What are these other static lists?=C2=A0 The only thing = I see listed in the
> > >> charter or the problem statement is the PSL.
> > >
> > > Suzanne and Jothan suggested language to fix that, because t= he PSL is
> > > the most visible one but others are maintaining their own.= =C2=A0 Certainly
> > > some CAs have claimed to have their own private lists.
> > >
> > >> I think where we disconnect here is that to me, it does = seem like there
> > is
> > >> a Really Big Difference between talking about delegation= s down the DNS
> > >> hierarchy and delegations across the tree.
> > >
> > > That's because you think this is related to delegations.= =C2=A0 It's _not_.
> > > Dyndns.com makes no delegations, and yet it is a "publi= c suffix" and
> > > names beneath it are officially unrelated to one another. > > > Blogspot.com is in the same boat.=C2=A0 Hkg1.afilias-nst.info and
> > > y= yz1.afilias-nst.info are different delegations (there's an SOA at > > > each) and are yet completely within the same administrative = control
> > > and in fact represent pieces of the very same sub-organizati= on's
> > > internal hierarchy.=C2=A0 The DNS hierarchy is _accidental_ = to this
> > > problem; that was the original sin in the Netscape cookies > > > specification.
> > >
> > >> Talking about arbitrary association of DNS names is a ve= ry different
> > >> question.=C2=A0 Now you have to talk about what sorts of= relationships you
> > want
> > >> to encode, which plunges you into a whole world of appli= cation-layer
> > >> semantics.
> > >
> > > I am claiming, and have been claiming for some time, that th= e
> > > inference from the parent-child relationship is _exactly_ th= e mistake,
> > > and in any case it doesn't help you with things like ant= i-abuse in
> > > messaging because the location in the hierarchy isn't ne= cessarily
> > > "parent."=C2=A0 So you actually have all this appl= ication-layer semantics
> > > already, and we're just pretending it's not there. > > >
> > >> I want to delegate my email to Provider X, but not my we= b or
> > >> XMPP services.=C2=A0 Do I use this DBOUND thing, or can = I only delegate the
> > >> whole domain with that?=C2=A0 This seems like a very dee= p and attractive
> > rathole.
> > >
> > > And we had a discssion about it in the past, and will need t= o talk
> > > about it over again, but SRV records and other such friends = already
> > > give us some hints about the way to proceed.
> > >
> > > If the goal is to get a sentence in the charter that basical= ly says,
> > > "The WG will maximise its use of existing techniques,&q= uot; I'm all on
> > > board for it.
> > >
> > >> It seems like the PSL / within-the-tree case is well und= erstood and
> > >
> > > Apparently not, or you wouldn't be focussing on delegati= on.=C2=A0 (This
> > > very confusion, which is astonishingly resistant to correcti= on, is
> > > indeed a serious problem.)
> > >
> > >> hand-wavy paragraph in the problem statement.=C2=A0 (Ser= iously, "somehow
> > >> associated"?)=C2=A0 Can that part simply be excised= for now, and maybe
> > brought
> > >> back in a re-charter when there's a clearer idea of = what "somehow
> > >> associated" means?
> > >
> > > I've already removed this notion repeatedly from drafts = I've written
> > > about this topic, because people keep insisting it's too= complicated.
> > > Later, it turns out that people realise that they already ha= ve the
> > > problem, and so it reappears.=C2=A0 I'm happy to remove = it again, though,
> > > if it will make you and others happy.=C2=A0 I predict it'= ;ll be back, but
> > > I'm certainly not devoted to it.
> > >
> > > A
> > >
> > > --
> > > Andrew Sullivan
> > > ajs@anvilwalrusden= .com
> > >
> >

--
Andrew Sullivan
ajs@anvilwalrusden.com

--001a11c2870a91e14b050da4c463-- From nobody Tue Jan 27 09:00: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 A6F3A1A886B; Tue, 27 Jan 2015 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 3A9jwvevrZfg; Tue, 27 Jan 2015 09:00:11 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADE11A8847; Tue, 27 Jan 2015 09:00:10 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C5C038A031; Tue, 27 Jan 2015 17:00:08 +0000 (UTC) Date: Tue, 27 Jan 2015 12:00:06 -0500 From: Andrew Sullivan To: Richard Barnes Message-ID: <20150127170006.GF1428@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Barry Leiba , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 27 Jan 2015 17:00:14 -0000 On Tue, Jan 27, 2015 at 11:30:07AM -0500, Richard Barnes wrote: > > I think it would be sufficient to just say, that "related" is not a unitary > concept, and that there will be different flavors of relationship. Excellent. I think this was exactly the difference we were having before, and I'm glad we now agree that it's part of the work for the WG, not pre-WG. Thanks! A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jan 27 14:31: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 40F361A9080 for ; Tue, 27 Jan 2015 14:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 2QOPiQIQdKSe for ; Tue, 27 Jan 2015 14:30:57 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367211A907D for ; Tue, 27 Jan 2015 14:30:57 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id s18so15961750lam.3 for ; Tue, 27 Jan 2015 14:30:55 -0800 (PST) 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=4k+3dB4mcQP8uQ2a3IlKEzXIs+GstrNW9BDGHFRaLXw=; b=DO6e8QTGTALyXTK4wqGjJnHD0Wjo3GFQVSXb9JiOrNxrzZK6f7UB57SbNLcdPJLZyP 3yuGrbtjmBWCKNmlXSwBi8DYhbb09pmvWPJRqpCVqdq1/rq9LqqJUBIa6jtIGot1Fove EYUoC1NEpcSUaNTeCCyvupTtCtVbd0ASJD/yUrXSlFlZHkVvduIFjQBT6Ghi+xAKqE11 NkCcVsJwqvHbuQSwrkEWS1gzE1HplLNzTLTSVIGYFHBd3EExzHu8DNL8y+x8wqix0Kql KHVZcWVmnt+oZe142EN6jkGZZtARb+VdqR0nmw2tPZI5GjqDjilb/tJlHbKnHP7hxkEN FX5w== X-Gm-Message-State: ALoCoQmAfTWDSokOFvRm6MNUYpNPHILiz95js2QJTRZz7mQ9JRC7U18SUibOS4E4H0VYQTw04+tz MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr4456878lbz.100.1422397855706; Tue, 27 Jan 2015 14:30:55 -0800 (PST) Received: by 10.25.201.86 with HTTP; Tue, 27 Jan 2015 14:30:55 -0800 (PST) In-Reply-To: <20150127170006.GF1428@mx1.yitter.info> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> Date: Tue, 27 Jan 2015 17:30:55 -0500 Message-ID: From: Richard Barnes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11345ed6eb5bf1050da9ce4a Archived-At: Cc: Barry Leiba , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) 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, 27 Jan 2015 22:30:59 -0000 --001a11345ed6eb5bf1050da9ce4a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 27, 2015 at 12:00 PM, Andrew Sullivan wrote: > On Tue, Jan 27, 2015 at 11:30:07AM -0500, Richard Barnes wrote: > > > > I think it would be sufficient to just say, that "related" is not a > unitary > > concept, and that there will be different flavors of relationship. > > Excellent. I think this was exactly the difference we were having > before, and I'm glad we now agree that it's part of the work for the > WG, not pre-WG. Thanks! > Great. I do think some text refactoring is necessary here, though. Let me know when you've got a proposal. --Richard > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > --001a11345ed6eb5bf1050da9ce4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jan 27, 2015 at 12:00 PM, Andrew Sullivan <ajs@anvilwalrusden= .com> wrote:
On Tue, Jan 27, 2015 at 11:30:07AM -0500, Richard Barnes wrote:
>
> I think it would be sufficient to just say, that "related" i= s not a unitary
> concept, and that there will be different flavors of relationship.

Excellent.=C2=A0 I think this was exactly the difference we were hav= ing
before, and I'm glad we now agree that it's part of the work for th= e
WG, not pre-WG.=C2=A0 Thanks!

Great.=C2= =A0 I do think some text refactoring is necessary here, though.=C2=A0 Let m= e know when you've got a proposal.

--Richard
=C2=A0

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

--001a11345ed6eb5bf1050da9ce4a--