From nobody Thu Mar 10 01:31:53 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9700012D616 for ; Thu, 10 Mar 2016 01:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUdatMVAS35G for ; Thu, 10 Mar 2016 01:31:49 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0412D5D9 for ; Thu, 10 Mar 2016 01:31:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 79A8010AA0 for ; Thu, 10 Mar 2016 09:31:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOaOH46Opgw6 for ; Thu, 10 Mar 2016 09:31:48 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2620:f:8000:210:d5e4:9ea0:4c2a:a6fd]) by mx2.yitter.info (Postfix) with ESMTPSA id 4F6F6105A5 for ; Thu, 10 Mar 2016 09:31:48 +0000 (UTC) Date: Thu, 10 Mar 2016 04:31:47 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160310093147.GC78383@mx2.yitter.info> References: <20160218230213.GR100@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160218230213.GR100@mx2.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] 2 draft updates X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 09:31:51 -0000 Hi, Since we're having no meeting in BA, are there any comments or observations about these changes? If not, is that an indication that the WG energy just isn't there? Best regards, A On Thu, Feb 18, 2016 at 06:02:13PM -0500, Andrew Sullivan wrote: > Hi all, > > I just uploaded a minor change to > draft-sullivan-dbound-problem-statement. This reflects the > inherit-or-not discussion we had in Yokohama. The discussion may not > yet be clear enough, and I confess I hate the terms, but we didn't > come up with anything better. > > While doing that, two of us have undertaken a substantial work-over of > draft-sullivan-dbound-problem-statement in order to make it somewhat > clearer. I continue to believe that approach solves more of the > problem I at least think we have than do other approaches. In > particular, I remain unconvinced that a simple public/private > distinction is going to do all the work we need. > > https://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/ > > and > > https://datatracker.ietf.org/doc/draft-sullivan-domain-policy-authority/ > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Mar 19 13:31:42 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB312D5BD for ; Sat, 19 Mar 2016 13:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI_DLKPP2fZz for ; Sat, 19 Mar 2016 13:31:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50D912D548 for ; Sat, 19 Mar 2016 13:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1458419498; x=1489955498; h=from:to:subject:date:message-id:mime-version; bh=zr6XgF3o4gojW/P6DfdIL93D7oFldJwZnbJNhUCN7Ak=; b=EbNIwboMvXW2GOB+HOz7Ddk0SDG6bH+/OybpFnqT4Bw5BfyS/NspZPun Cz6+zfG8mPM/eO1wq/LqRVsPZ5IozkoXP7mPseGcz61X6XDfFc1jOXj6v PAHyCXhJrcQY+ElgPKKw4/8cqWJmwLCWlTOftSL33ZepRDbB8Dw2K9VhO U=; X-IronPort-AV: E=Sophos;i="5.24,362,1455004800"; d="scan'208,217";a="178268442" Received: from ironmsg03-l-new.qualcomm.com (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2016 13:31:38 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8109"; a="1113876897" Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Mar 2016 13:31:38 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.85.0.32) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 19 Mar 2016 13:31:38 -0700 Received: from NASANEXM01F.na.qualcomm.com ([10.85.0.32]) by NASANEXM01F.na.qualcomm.com ([10.85.0.32]) with mapi id 15.00.1130.005; Sat, 19 Mar 2016 13:31:37 -0700 From: "Resnick, Pete" To: "dbound@ietf.org" Thread-Topic: On (not) moving forward Thread-Index: AQHRgh5VbV4Cky/Gk0WXpAX0rtvX1A== Date: Sat, 19 Mar 2016 20:31:37 +0000 Message-ID: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_473d619b6c614fceab703c34623afe37NASANEXM01Fnaqualcommco_" MIME-Version: 1.0 Archived-At: Subject: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 20:31:41 -0000 --_000_473d619b6c614fceab703c34623afe37NASANEXM01Fnaqualcommco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colleagues, Your co-chairs and supervising AD have been discussing the apparent lack of= progress toward setting definitive milestones for the DBOUND working group= . Since chartering almost a year ago, three proposals have been submitted to = the WG for consideration. While the authors of those documents have our th= anks for the effort put into producing them and keeping them alive, no clea= r consensus has developed to proceed with any of them. Indeed, there is no= t even consensus on the problem statement document. At this point, we would like the working group to consider and discuss why = we appear to be entrenched, and what might get us moving. Are there resour= ces we need that we don't have? Is there additional expertise we should re= cruit? Are apathy and NIH (Not Invented Here) the only problems? We feel this is work the IETF really should be doing. If it does not, indu= stry will be left to come up with its own solution to the problem. We trust= we don't need to recount for anyone reading this what an unpleasant experi= ence we had When industry felt that the IETF had failed it in terms of emai= l security and created and imposed DMARC. Obviously the above cannot, in the absence of visible progress, sustain the= existence of the working group indefinitely, so we would like to encourage= progress somehow. Failure to do so will obviously result in termination o= f the working group. Attempting to re-create it later when we think there's= momentum again will be more difficult as we'll have to convince the IESG t= hat things will be better. Another option is to try to reassign the proble= m to the DNSOP working group (with the same impetus we described above) and= see what they propose. Please reply on this thread with suggestions to get the WG moving. If you = are an author, perhaps you should revitalize discussion of your draft. If = you have never commented on any document, such comments would be very valua= ble now. If you have suggestions for others whose opinions we should seek,= please suggest them. If there are useful resources your co-chairs should = seek, please request them. We are at your service, Pete & Murray, DBOUND co-chairs --_000_473d619b6c614fceab703c34623afe37NASANEXM01Fnaqualcommco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colleagues,

Your co-chairs and supervising AD have been discussing the apparent lack of= progress toward setting definitive milestones for the DBOUND working group= .

Since chartering almost a year ago, three proposals have been submitted to = the WG for consideration.  While the authors of those documents have o= ur thanks for the effort put into producing them and keeping them alive, no= clear consensus has developed to proceed with any of them.  Indeed, there is not even consensus on the problem= statement document.

At this point, we would like the working group to consider and discuss why = we appear to be entrenched, and what might get us moving.  Are there r= esources we need that we don't have?  Is there additional expertise we= should recruit?  Are apathy and NIH (Not Invented Here) the only problems?

We feel this is work the IETF really should be doing.  If it does not,= industry will be left to come up with its own solution to the problem.&nbs= p;We trust we don't need to recount for anyone reading this what an unpleas= ant experience we had When industry felt that the IETF had failed it in terms of email security and created and imposed = DMARC.

Obviously the above cannot, in the absence of visible progress, sustain the= existence of the working group indefinitely, so we would like to encourage= progress somehow.  Failure to do so will obviously result in terminat= ion of the working group. Attempting to re-create it later when we think there's momentum again will be more di= fficult as we'll have to convince the IESG that things will be better. = ; Another option is to try to reassign the problem to the DNSOP working gro= up (with the same impetus we described above) and see what they propose.

Please reply on this thread with suggestions to get the WG moving.  If= you are an author, perhaps you should revitalize discussion of your draft.=   If you have never commented on any document, such comments would be = very valuable now.  If you have suggestions for others whose opinions we should seek, please suggest them.  If th= ere are useful resources your co-chairs should seek, please request them.
We are at your service,

Pete & Murray, DBOUND co-chairs
--_000_473d619b6c614fceab703c34623afe37NASANEXM01Fnaqualcommco_-- From nobody Sat Mar 19 17:40:19 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CECE12D65D for ; Sat, 19 Mar 2016 17:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKP65jdfhiKY for ; Sat, 19 Mar 2016 17:40:16 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A2A12D65C for ; Sat, 19 Mar 2016 17:40:16 -0700 (PDT) Received: (qmail 65629 invoked from network); 20 Mar 2016 00:40:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Mar 2016 00:40:15 -0000 Date: 20 Mar 2016 00:39:53 -0000 Message-ID: <20160320003953.39721.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: presnick@qti.qualcomm.com Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 00:40:18 -0000 >At this point, we would like the working group to consider and discuss why we appear to be entrenched, and what might get us moving. I've been scratching my head, too. As best I can tell, this is one of those problems where the more you think about it, the more twisty passages there are. So perhaps a revised goal would be to ask what is a minimal design that would still be better than downloading the PSL? I shamelessly argue that my draft is probably it. The lookups are fast, one plus the number of boundaries in a name (not the number of name components), the names can be self-published within the domain's tree, or in a third party tree, and it can handle different applications with different boundaries. The Decchio draft requires a new _odup top-level domain which I think makes it a non-starter, and the lookup process is so complex I don't entirely understand it but it appears I think it can involve tree walking. (Casey said that he had another version without a separate TLD, but if he's posted it I can't find it.) The Yao draft still has problems with wildcard semantics. I'm not arguing mine is perfect; Deccio can identify both boundary domains (co.uk) and organizational domains (example.com) which I don't, my organizational domains are implicit, so we might want to add some of his qualifiers. Andrew's always wanted to do cross-tree relationships, e.g., example.org is the same as example.com, but as far as I know nobody's come up with a way to do that without putting boundary records on every name in a subtree that might be related to something else. So how about if we pick a draft, preferably mine, and say either it's good enough to move ahead, or else say why it isn't. R's, John From nobody Sun Mar 20 19:13:13 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91F312D55D for ; Sun, 20 Mar 2016 19:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL7fXUwWu3pP for ; Sun, 20 Mar 2016 19:13:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB5212D52F for ; Sun, 20 Mar 2016 19:13:09 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.153]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QDiuWO9W_w9PCQ--.57146S2; Mon, 21 Mar 2016 10:13:06 +0800 (CST) Date: Mon, 21 Mar 2016 10:13:04 +0800 From: "Jiankang Yao" To: =?iso-8859-1?B?UmVzbmljaywgUGV0ZQ==?= , dbound References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2016032110114814858510@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart526434672825_=----" X-CM-TRANSID: AQAAf0A5QDiuWO9W_w9PCQ--.57146S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw43Jr17Xw15Kry3Kr4fGrg_yoW8Xr17pF sIgF12k39rArWxKw1qv3WUWr4Iyrs5Wa13JFn8J34DA3y5Gr1aqa47K34Y9ry5Ca1vkF4v qF4xur9xAFyqvaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjc xK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E 42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72 CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wAC Y4xI67k04243AVC20s07MxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4 IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1r MI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJV WUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3 Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8Jw CE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07b5q2_UUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Jiankang List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 02:13:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart526434672825_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQoNCg0KRnJvbTogUmVzbmljaywgUGV0ZQ0KRGF0ZTogMjAxNi0wMy0yMCAwNDozMQ0KVG86IGRi b3VuZEBpZXRmLm9yZw0KU3ViamVjdDogW2Rib3VuZF0gT24gKG5vdCkgbW92aW5nIGZvcndhcmQN Cg0KDQpXZSBmZWVsIHRoaXMgaXMgd29yayB0aGUgSUVURiByZWFsbHkgc2hvdWxkIGJlIGRvaW5n LiAgSWYgaXQgZG9lcyBub3QsIGluZHVzdHJ5IHdpbGwgYmUgbGVmdCB0byBjb21lIHVwIHdpdGgg aXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4gV2UgdHJ1c3Qgd2UgZG9uJ3QgbmVlZCB0 byByZWNvdW50IGZvciBhbnlvbmUgcmVhZGluZyB0aGlzIHdoYXQgYW4gdW5wbGVhc2FudCBleHBl cmllbmNlIHdlIGhhZCBXaGVuIGluZHVzdHJ5IGZlbHQgdGhhdCB0aGUgSUVURiBoYWQgZmFpbGVk IGl0IGluIHRlcm1zIG9mIGVtYWlsIHNlY3VyaXR5IGFuZCBjcmVhdGVkIGFuZCBpbXBvc2VkIERN QVJDLg0KDQpbSmlhbmthbmcgWWFvXSB5ZXMsIGFncmVlLiBhbm90aGVyIGV4YW1wbGUgb3IgdXNl IGNhc2UgaXMgdGhhdCBzaW1wbGlmaWVkIENoaW5lc2UgdmVyc2lvbiBhbmQgdHJhZHRpb25hbCBD aGluZXNlIHZlcnNpb24gb2YgLkNoaW5hIElETiBUTEQgY2FuIHVzZSBkYm91bmQgdG8gdGVsbCB0 aGUgYXBwbGljYXRpb24gb3IgdXNlcnMgdGhhdCAgdGhlIHNhbWUgbGFiZWwgdW5kZXIgYm90aCB2 ZXJzaW9ucyBvZiAuQ2hpbmEgSUROIFRMRCBiZWxvbmcgdG8gdGhlIHNhbWUgcmVnaXN0cmFudCBh bmQgc2hhcmUgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgcG9saWN5LiAgDQoNCkkgdGhpbmsgdGhh dCBpdCBpcyBhbHNvIHRydWUgZm9yIC5OR08gYW5kIC5PTkcgVExEcy4gVGhlc2UgMiBUTERzIGFy ZSBzdXBwb3NlZCB0byBoYXZlIGEgYnVuZGxlZCBuYW1lIHJlZ2lzdHJhdGlvbi4gIE1hbnkgdXNl cnMgd2lsbCBsaWtlIHRvIGhhdmUgdGhlIG5hbWVzIHVuZGVyIHRoZXNlIDIgdGxkcyBzaGFyZSB0 aGUgIHNhbWUgYWRtaW5pc3RyYXRpdmUgcG9saWN5Lg0KIA0KDQoNClBsZWFzZSByZXBseSBvbiB0 aGlzIHRocmVhZCB3aXRoIHN1Z2dlc3Rpb25zIHRvIGdldCB0aGUgV0cgbW92aW5nLiAgSWYgeW91 IGFyZSBhbiBhdXRob3IsIHBlcmhhcHMgeW91IHNob3VsZCByZXZpdGFsaXplIGRpc2N1c3Npb24g b2YgeW91ciBkcmFmdC4gIElmIHlvdSBoYXZlIG5ldmVyIGNvbW1lbnRlZCBvbiBhbnkgZG9jdW1l bnQsIHN1Y2ggY29tbWVudHMgd291bGQgYmUgdmVyeSB2YWx1YWJsZSBub3cuICBJZiB5b3UgaGF2 ZSBzdWdnZXN0aW9ucyBmb3Igb3RoZXJzIHdob3NlIG9waW5pb25zIHdlIHNob3VsZCBzZWVrLCBw bGVhc2Ugc3VnZ2VzdCB0aGVtLiAgSWYgdGhlcmUgYXJlIHVzZWZ1bCByZXNvdXJjZXMgeW91ciBj by1jaGFpcnMgc2hvdWxkIHNlZWssIHBsZWFzZSByZXF1ZXN0IHRoZW0uDQoNCltKaWFua2FuZyBZ YW9dIEkgdGhpbmsgdGhhdCB0aGUgV0cgbWF5IHB1c2ggb3IgZm9jdXMgb24gdGhlIHByb2JsZW0g c3RhdGVtZW50IGZpcnN0IC4= ------=_001_NextPart526434672825_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
 
Date: 2016-03-20 04:31
Subject: [dbound] On (not) moving forward


We feel this is work the I= ETF=20 really should be doing.  If it does not, industry will be left to com= e up=20 with its own solution to the problem. We trust we don't need to recou= nt for=20 anyone reading this what an unpleasant experience we had When industry fel= t that=20 the IETF had failed it in terms of email security and created and imposed=20 DMARC.
=
[Jiankang=20 Yao] yes, agree. another example or use case is that simplif= ied=20 Chinese version and tradtional Chinese version of .China IDN TLD can = use=20 dbound to tell the application or users that  the = ;same=20 label under both versions of .China IDN TLD belon= g to=20 the same registrant and share the same administrative=20 policy.  

I think that it is also true for .NGO and .ONG TLDs. These 2 TLDs are supposed to= have a=20 bundled name registration.  Many users will like to have th= e=20 names under these 2 tlds share the =20 same administrative policy.
 


Plea= se=20 reply on this thread with suggestions to get the WG moving.  If you a= re an=20 author, perhaps you should revitalize discussion of your draft.  If y= ou=20 have never commented on any document, such comments would be very valuable= =20 now.  If you have suggestions for others whose opinions we should see= k,=20 please suggest them.  If there are useful resources your co-chairs sh= ould=20 seek, please request them.

= [Jiankang=20 Yao] I think that the WG may push or focus on the problem stateme= nt=20 first .
------=_001_NextPart526434672825_=------ From nobody Sun Mar 20 19:43:38 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1512D5C8 for ; Sun, 20 Mar 2016 19:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9O6zrB0d7Vq for ; Sun, 20 Mar 2016 19:43:35 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E2112D52F for ; Sun, 20 Mar 2016 19:43:35 -0700 (PDT) Received: (qmail 20957 invoked from network); 21 Mar 2016 02:43:34 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Mar 2016 02:43:34 -0000 Date: 21 Mar 2016 02:43:12 -0000 Message-ID: <20160321024312.44325.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <2016032110114814858510@cnnic.cn> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: yaojk@cnnic.cn Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 02:43:37 -0000 >.China IDN TLD can use dbound to tell the application or users that the same label under both versions of .China IDN TLD >belong to the same registrant and share the same administrative policy. > >I think that it is also true for .NGO and .ONG TLDs. These 2 TLDs are supposed to have a bundled name registration. You are correct here. (I know since I have a .NGO/.ONG domain.) This points out that there are two different kinds of cross-tree relationships that are of interest. One is the kind of relationship you described, parallel subtrees, so it would be useful to have some way to say that .ong and .ngo are under the same control for all names. Another point that Andrew made a while ago is that there are often multiple domains under the same control with no syntactic relation. For example, the domains google.com and 1e100.com are in fact run by the same people, even though the names aren't related. For the parallel subtrees, I'm wondering whether the points of relation are all at the TLD and if so, some limited kludge would do the trick. Hmmn. I also wonder how important it is in both cases to handle relationships among more than two trees. For example. the Indian ccTLD controls .in .ভারত .భారత్ .ભારત .भारत .بھارت‎ .ਭਾਰਤ and .இந்தியா. I don't know whether they're all supposed to be equivalent or whether there are separate registrations in each. R's, John From nobody Mon Mar 21 03:53:25 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0B12D501 for ; Mon, 21 Mar 2016 03:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x52ebgvt3UL6 for ; Mon, 21 Mar 2016 03:53:21 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FAD12D6A4 for ; Mon, 21 Mar 2016 03:47:08 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id r129so44692645wmr.1 for ; Mon, 21 Mar 2016 03:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=3lgj27OklFkFIE+2ZZwBfS972tf2iULtGZCF8BIGfAo=; b=kLSsdDGO9Tc4PoCxXveSIkFmVvbPG2AQZu2kbfVNdVGx9JdejiO0nqoNpK/emotW30 SNgPPUTVRwKyzojYoXMtMOiumQClgA8YkZMAa5n+RC9QyKvBTQZnEEiXijzoCl9Sb1s9 sdCf8+GBS0qNIleGnvqce31Gv0iXQ6jKjk7xctUhVmJJJIJFuYv4WaUWfXszq4vrys6W f3aurMwsk7sSepUv/dglyR18eOVn3bIwJTNwJ0AplkniePEgSfjahn2UgH2ZL9CeUqZ4 7PGQOiqAZJN5XCHoWPnXix6LMu7Pl1BHJSuydbw7l052ZGDFmrEGhK8e8cqOKZQT74+n XknA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3lgj27OklFkFIE+2ZZwBfS972tf2iULtGZCF8BIGfAo=; b=GBTWRCu0hbWZtjoEQF4mAKTdU2ZVe31SHKB1r1ky6IRVYbdoCSEgoLcaJiucdRsF3B WEsMrr1Aj06NGkJ9mL4x9xo7WzA0jZ7futHDyVLLjXe1PYypgHDwMLDtWX22UF1twPfo 3IOjBCjKXfWgnn87HCb2fXSjZ3pUkeJpw3fsT2TaHns/JrVfv7lMPSvbWjXJvw0Q1eUs LRJXOQVkEPwV1Kg+62IalPy9oaNgy5ImQsbP3TZJbTyO2byLIeoBi1gFtl/w9V9/LGMo m78yFNmzzmTbw4uHhtZEieGQH661ZgQABQ9u5M8S29SQXe1XKPW+jv+gv9ec93ih9TYN KS3Q== X-Gm-Message-State: AD7BkJKKaUkUEEecflIkQR+WlovcBT3S6/Lmqojh3THu/HSPjWjhOMBY2u70F1zLcH38SSVH X-Received: by 10.28.47.21 with SMTP id v21mr13671322wmv.7.1458557227225; Mon, 21 Mar 2016 03:47:07 -0700 (PDT) Received: from [192.168.0.124] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by smtp.gmail.com with ESMTPSA id i1sm24606701wjs.45.2016.03.21.03.47.05 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 03:47:05 -0700 (PDT) To: dbound@ietf.org References: <20160320003953.39721.qmail@ary.lan> From: Gervase Markham Message-ID: <56EFD129.7050605@mozilla.org> Date: Mon, 21 Mar 2016 10:47:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160320003953.39721.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:53:24 -0000 On 20/03/16 00:39, John Levine wrote: >> At this point, we would like the working group to consider and >> discuss why we appear to be entrenched, and what might get us >> moving. > > I've been scratching my head, too. As best I can tell, this is one > of those problems where the more you think about it, the more twisty > passages there are. So perhaps a revised goal would be to ask what > is a minimal design that would still be better than downloading the > PSL? I've been lurking on this list but I don't feel I have much to add to the discussion - because while I am part of the team that maintains the PSL, I don't have a good grasp of the capabilities of the alternative technologies which are being proposed as foundations for replacing it. However, it does strike me that "being better than downloading the PSL" is actually a higher bar than one could think, because any online technology starts (at least, from the point of view of many implementers) with the handicap of requiring some number of additional time-consuming network lookups. So it has to be quite a bit better in other ways to be better than the PSL overall. I wonder if the continued persistence of the PSL is a good example of "worse is better"? https://en.wikipedia.org/wiki/Worse_is_better Perhaps a design goal of the new system (and I don't know which, if any drafts, meet this goal) would be the ability to somehow scan the live information across the entire Internet and re-construct the PSL on a regular basis for those applications for which regular network lookups are too costly? Gerv From nobody Mon Mar 21 12:07:09 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD112D8EC for ; Mon, 21 Mar 2016 12:07:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXhgKuonG5gK for ; Mon, 21 Mar 2016 12:07:05 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E01B12DACF for ; Mon, 21 Mar 2016 12:05:49 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r129so63522422wmr.1 for ; Mon, 21 Mar 2016 12:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ieYYIT7ec2MRuEZAJrcAWJI1v63TBuEwbazsTe50XfE=; b=P9lfIQp9YcBtfgPK/8kwovjzeYaGdAQt8AWK1xaFr3HkCsFSlUtQUMyDC3bWpjK0FV OF4ge12HGCZoCKSdiYXhGbSVfecMMjdyo5Ir65r00XeqTc66rL8xKUV/6gPHm/WRlxhK ITKAp7hxQOKC0kThX9U4dSZ1LQxnPW+5DXY+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ieYYIT7ec2MRuEZAJrcAWJI1v63TBuEwbazsTe50XfE=; b=D00Ll4yMCYEIYCCnSq0N3dEM3O92NzIWEwtQR0mBKTePya6s1V1KAiEOdLeKvcYZkT qnRPnCb5XlNwe3euICFZV8QvnMIYOg3zwgAaA1q2N2ydhFG+2oyioZfouWxTbc5CkTjY 7tCyzbD8hf6RCVdaCY5AT3960+5nU4QHb8mDCOO5gMvN9dGlccH6UTxjdwYPW+Hfrypa itwwTpt7KatdHYbmGKEEb7KlktA3CxSO5UgSblOXLGWpCOhSeJ4TRy6zMJJPdynssWin DBL11+XdOGl8eto7b+Qa5ljU7NVjqOvTkKToP2RkB/2SxCZDINii+qwoLnWdYzjRQwsS P0xA== X-Gm-Message-State: AD7BkJJVFQOVrM0pp4sto1d5vX2s56eoN0IpASCZUAg8LyplHm0xXb3kkiivmTfOLbWwZuVIzGRd6MVwg5NAWg== MIME-Version: 1.0 X-Received: by 10.28.172.194 with SMTP id v185mr15054220wme.21.1458587147634; Mon, 21 Mar 2016 12:05:47 -0700 (PDT) Received: by 10.194.9.170 with HTTP; Mon, 21 Mar 2016 12:05:47 -0700 (PDT) In-Reply-To: <20160320003953.39721.qmail@ary.lan> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <20160320003953.39721.qmail@ary.lan> Date: Mon, 21 Mar 2016 15:05:47 -0400 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=001a1141ec7ecf28a5052e93c8e5 Archived-At: Cc: presnick@qti.qualcomm.com, "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:07:08 -0000 --001a1141ec7ecf28a5052e93c8e5 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 19, 2016 at 8:39 PM, John Levine wrote: > So perhaps a revised goal would be to ask what is > a minimal design that would still be better than downloading the PSL? > "Better" is a very ambiguous and subjective term. A number of desirable solution characteristics have been discussed on the mailing list and in meetings, whose use here would be more appropriate. > The Decchio draft requires a new _odup top-level domain which I think > makes it a non-starter s/Decchio/Deccio/ The -02 version will not require a new _odup TLD. The -02 version is nearly ready to be published, but is still undergoing internal review. > and the lookup process is so complex I don't > entirely understand it I have yet to see an in-depth review of the draft from you. The mechanism in the -02 version is nearly the same as it is in the -01 version, with the exception that the client begins the lookup process at the TLD (e.g., _ odup.com.) rather than at the root. So you can still start your review with the -01 version until -02 is ready, given this understanding. One of the strongest characteristics of the approach in the Deccio draft is careful consideration of existing behaviors to preserve compatibility with current (i.e., PSL) solutions. Any perceived complexities from the approach likely result from that. The algorithm itself is actually straight-forward: walk (i.e., using DNS queries) the name downward from its TLD to identify 1) the organizational domain for the name and 2) the policy associated with the name. The responses to each query (e.g., NXDOMAIN, NODATA, +bound, +org) indicate which DNS name to query next in the walk downward. There are plenty of examples in the document, in the form of example names, ODUP statements, lookup sequences, and resulting policy. There is also example code at: https://github.com/verisign/odup (With the -02 version of the draft the example code will also be updated.) A few other comments on the -02 version (to be published...) of draft-deccio-dbound-organizational-domain-policy: - Bootstrapping - As mentioned previously in this message, bootstrapping the lookup process begins with the TLD, not with the root. Each TLD hosts a "_odup" subdomain which is consulted for policy information for subdomains of the TLD itself. There is no longer a notion of a _odup TLD. - Fetch - The "+fetch" directive allows clients to download policies of TLDs and arbitrary (e.g., high use) domains ahead of time to avoid the real-time lookup, which can be expensive. - PSL reproduction - Gerv mentioned reconstruction of the existing PSL. This is inherent in the design of the -02 version of the draft. Whether for performance enhancement or for backwards compatibility with applications currently using the PSL, the PSL can be reproduced from ODUP statements at TLDs (and other domains), just as the ODUP statements at TLDs (and other domains) can be created from the PSL. This is an essential characteristic of a usable solution. Note that the code to be published alongside the -02 version of the draft demonstrates this capability. Cheers, Casey --001a1141ec7ecf28a5052e93c8e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 19, 2016 at 8:39 PM, John Levine <johnl@taugh.c= om> wrote:
So perhaps a revis= ed goal would be to ask what is
a minimal design that would still be better than downloading the PSL?

"Better" is a very ambiguous and s= ubjective term.=C2=A0 A number of desirable solution characteristics have b= een discussed on the mailing list and in meetings, whose use here would be = more appropriate.
=C2=A0
The Decchio draft requires a new _odup top-level domain which I think
makes it a non-starter

s/Decchio/Deccio/
The -02 version will not require a new _odup TLD.=C2=A0 The= -02 version is nearly ready to be published, but is still undergoing inter= nal review.
=C2=A0
and the lookup process is so complex I don't
entirely understand it

I have yet to see an in-d= epth review of the draft from you.=C2=A0 The mechanism in the -02 version i= s nearly the same as it is in the -01 version, with the exception that the = client begins the lookup process at the TLD (e.g., _odup.com.) rather than at the root.=C2=A0 So you= can still start your review with the -01 version until -02 is ready, given= this understanding.

One of the strongest characteristics of the app= roach in the Deccio draft is careful consideration of existing behaviors to= preserve compatibility with current (i.e., PSL) solutions.=C2=A0 Any perce= ived complexities from the approach likely result from that.=C2=A0 The algo= rithm itself is actually straight-forward: walk (i.e., using DNS queries) t= he name downward from its TLD to identify 1) the organizational domain for = the name and 2) the policy associated with the name.=C2=A0 The responses to= each query (e.g., NXDOMAIN, NODATA, +bound, +org) indicate which DNS name = to query next in the walk downward.

There are plenty of e= xamples in the document, in the form of example names, ODUP statements, loo= kup sequences, and resulting policy.=C2=A0 There is also example code at: <= a href=3D"https://github.com/verisign/odup" target=3D"_blank">https://githu= b.com/verisign/odup

(With the -02 version of the draf= t the example code will also be updated.)

A few other com= ments on the -02 version (to be published...) of draft-deccio-dbound-organi= zational-domain-policy:

- Bootstrapping - As mentioned pr= eviously in this message, bootstrapping the lookup process begins with the = TLD, not with the root.=C2=A0 Each TLD hosts a "_odup" subdomain = which is consulted for policy information for subdomains of the TLD itself.= =C2=A0 There is no longer a notion of a _odup TLD.
- Fetch - = The "+fetch" directive allows clients to download policies of TLD= s and arbitrary (e.g., high use) domains ahead of time to avoid the real-ti= me lookup, which can be expensive.
- PSL reproduction - Gerv = mentioned reconstruction of the existing PSL.=C2=A0 This is inherent in the= design of the -02 version of the draft.=C2=A0 Whether for performance enha= ncement or for backwards compatibility with applications currently using th= e PSL, the PSL can be reproduced from ODUP statements at TLDs (and other do= mains), just as the ODUP statements at TLDs (and other domains) can be crea= ted from the PSL.=C2=A0 This is an essential characteristic of a usable sol= ution.=C2=A0 Note that the code to be published alongside the -02 version o= f the draft demonstrates this capability.

Cheers,
Casey
--001a1141ec7ecf28a5052e93c8e5-- From nobody Mon Mar 21 13:15:52 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49212DB3A for ; Mon, 21 Mar 2016 13:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3b4sxTy5zYC for ; Mon, 21 Mar 2016 13:15:46 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E4512DB4C for ; Mon, 21 Mar 2016 13:15:32 -0700 (PDT) Received: (qmail 88450 invoked from network); 21 Mar 2016 16:15:30 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Mar 2016 16:15:30 -0000 Date: 21 Mar 2016 16:15:08 -0000 Message-ID: <20160321161508.47873.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <56EFD129.7050605@mozilla.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: gerv@mozilla.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:15:51 -0000 >Perhaps a design goal of the new system (and I don't know which, if any >drafts, meet this goal) would be the ability to somehow scan the live >information across the entire Internet and re-construct the PSL on a >regular basis for those applications for which regular network lookups >are too costly? DNS caches get you a lot of that already. R's, John From nobody Mon Mar 21 13:20:49 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8052A12D727 for ; Mon, 21 Mar 2016 13:20:48 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxtNoS0hUZOz for ; Mon, 21 Mar 2016 13:20:47 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA48E12D998 for ; Mon, 21 Mar 2016 13:20:46 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l68so166238241wml.0 for ; Mon, 21 Mar 2016 13:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+5AoadPF2daUve+cSPGqcYLNcv0q54DD1KeZp2yy3dg=; b=WUM+qazxytttbBLk3NhLQYPSEc+PZwAYgwIfT6CtKDd4gSwppTBi6toW31V6trnxL/ op1VTEgjdn03sB1+Pmb20qelrwQgentqvjq0f0n7YG4SmNy1U4vNsgJkrgYL8Ukqxwxu sCTX7QPOLqu0oX60J+EwM+JDwZA09nanVFFmc= 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; bh=+5AoadPF2daUve+cSPGqcYLNcv0q54DD1KeZp2yy3dg=; b=Lb+HqA+iYr0VbzsVLdWzZ0VObIk94GJECWXh3bH2MoPeuMm03AA7a+3w2+AMa2N7u8 AeV17OGZn18lVW6JnqxiDJr0vZiUtx3nJfHOqL93qYOl1R04rISdx/ATqLJVhTwWNcfZ FUKhQTV0DWPj5+svNLKYtRrPN136CSzA463stJNEH6uRAd26vQUG58qaUnMmMd3Irg5n 5FBbZW1640z+Muao/aWriLApnocU/1IetY6FisvEIoa2VpkJMTZZ2YAS7SJ5857xutiX aEWS/OCVdXAqom6gT4yX6fip3SpKsnvUwy4f3aGpfDk53ZDguO26S4mMo5fal8rYUGoB MJZQ== X-Gm-Message-State: AD7BkJLs9+aJ2LF89WXi1BJ1ZBhDATIojFq5+GoEkn+gmhdS5CdK9ysPkv0bDzXcngIajVLefuzqxGMrUlMBQQ== MIME-Version: 1.0 X-Received: by 10.28.10.149 with SMTP id 143mr15267574wmk.38.1458591645548; Mon, 21 Mar 2016 13:20:45 -0700 (PDT) Received: by 10.194.9.170 with HTTP; Mon, 21 Mar 2016 13:20:45 -0700 (PDT) In-Reply-To: <20160321161508.47873.qmail@ary.lan> References: <56EFD129.7050605@mozilla.org> <20160321161508.47873.qmail@ary.lan> Date: Mon, 21 Mar 2016 16:20:45 -0400 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=001a11444df0e7db31052e94d4cd Archived-At: Cc: Gervase Markham , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:20:48 -0000 --001a11444df0e7db31052e94d4cd Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 12:15 PM, John Levine wrote: > >Perhaps a design goal of the new system (and I don't know which, if any > >drafts, meet this goal) would be the ability to somehow scan the live > >information across the entire Internet and re-construct the PSL on a > >regular basis for those applications for which regular network lookups > >are too costly? > > DNS caches get you a lot of that already. > > DNS resolvers retrieve and cache information on-demand when queried for it by clients. That means there is still a penalty 1) for the initial and subsequent cache misses and addtionally 2) for every lookup from application to DNS resolver. Casey --001a11444df0e7db31052e94d4cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 21, 2016 at 12:15 PM, John Levine <johnl@taugh.= com> wrote:
>Perhaps a desig= n goal of the new system (and I don't know which, if any
>drafts, meet this goal) would be the ability to somehow scan the live >information across the entire Internet and re-construct the PSL on a >regular basis for those applications for which regular network lookups<= br> >are too costly?

DNS caches get you a lot of that already.


DNS resolvers retrieve and cache infor= mation on-demand when queried for it by clients.=C2=A0 That means there is = still a penalty 1) for the initial and subsequent cache misses and addtiona= lly 2) for every lookup from application to DNS resolver.
Casey
--001a11444df0e7db31052e94d4cd-- From nobody Mon Mar 21 13:29:58 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0C12DAE8 for ; Mon, 21 Mar 2016 13:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWAmQL3n2K4x for ; Mon, 21 Mar 2016 13:29:47 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543C712D5F4 for ; Mon, 21 Mar 2016 13:29:34 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id oe12so135300843lbc.0 for ; Mon, 21 Mar 2016 13:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=52wr4ISogGLoUqq5sir4NZInyU6ibkEtb5CbCuV1fDY=; b=GLJB+QZjsb+AmR8osaKo+WRxhFkFMiNYzXJy/V71NDR9/FlhudPgQiXMuBUEHlfFbS lMyW2d+2EnvfxliZI+AegNtgCWHQxRC6KXq280oCTMNEO5qmPaXlg/7ktYhJLnkGdjYS 5mopm1hR02VqenXpYKMa7UmQ3anCWnSVKHgxo99PPiydaf9mqpZ5achnZnl+FFtvEAxB nDX+76gbsP6yHUjAG8Efgc5Gda+n4k4awpz2Obi2DQgvJr/A6uLuugOjNWovGqjD5CMX +r1zcPF2C6OngcfPK3C1DfWVPCUQLpflc1OmN1dhs63MRoYBLx8YzauNTIvcJN6kZifA L31w== 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; bh=52wr4ISogGLoUqq5sir4NZInyU6ibkEtb5CbCuV1fDY=; b=BeBOVupLB/EljAgDBqzwLveZjKqFNmurIrC5Q5he3Vb8gF0bIgUpmYF1XTyjbdpHtA +skiChIiiq9vwzKukx6xYPYG8yVmFr+kS89Q63Tm0fmWNPqvL1Uvy6PB6Ud+cVfx94sv ZOVyx9yz2EUU08jIQrFrYp1S7eHnmk2QU0sHaeo7khHRA4KedFnc5WNNUvEmcoYCAZAb akKhBmz2ibQhGnfFnyKQv/op5fzJxtZXj4ahLjj6lYGInu8AcS6rVSCkN3vdtcKxL75O WNXqQU0qvg6HtpTxzc/gfX8qDi+0J56LU/qn8DsMxfXyUuComsbZuSBCIRqMgzoZtolX E54w== X-Gm-Message-State: AD7BkJIsPOYRUCND0u3oy37jt/9uKtaIxS759WRyG87yadlkYoP0CGNa0b5gNox3banGw2ohN3QiBNV3OTtJKQ== MIME-Version: 1.0 X-Received: by 10.25.141.82 with SMTP id p79mr12364980lfd.42.1458592172592; Mon, 21 Mar 2016 13:29:32 -0700 (PDT) Received: by 10.25.141.72 with HTTP; Mon, 21 Mar 2016 13:29:32 -0700 (PDT) Received: by 10.25.141.72 with HTTP; Mon, 21 Mar 2016 13:29:32 -0700 (PDT) In-Reply-To: References: <56EFD129.7050605@mozilla.org> <20160321161508.47873.qmail@ary.lan> Date: Mon, 21 Mar 2016 13:29:32 -0700 Message-ID: From: Jothan Frakes To: Casey Deccio Content-Type: multipart/alternative; boundary=001a11401c7a51f18a052e94f49c Archived-At: Cc: John Levine , Gerv Markham , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:29:55 -0000 --001a11401c7a51f18a052e94f49c Content-Type: text/plain; charset=UTF-8 +1 to John's comment And something to consider wrt Casey's point On Mar 21, 2016 1:20 PM, "Casey Deccio" wrote: > > On Mon, Mar 21, 2016 at 12:15 PM, John Levine wrote: >> >> >> DNS caches get you a lot of that already. >> > > DNS resolvers retrieve and cache information on-demand when queried for it by clients. That means there is still a penalty... ..and potential "intervention" vector where zones may not be utilizing DNSSEC --001a11401c7a51f18a052e94f49c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 to John's comment

And something to consider wrt Casey's point

On Mar 21, 2016 1:20 PM, "Casey Deccio" <casey@deccio.net> wrote:
>
> On Mon, Mar 21, 2016 at 12:15 PM, John Levine <johnl@taugh.com> wrote:
>>
>>
>> DNS caches get you a lot of that already.
>>
>
> DNS resolvers retrieve and cache information on-demand when queried fo= r it by clients.=C2=A0 That means there is still a penalty...

..and potential "intervention" vector where zones = may not be utilizing DNSSEC

--001a11401c7a51f18a052e94f49c-- From nobody Mon Mar 21 14:13:51 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2112D90A for ; Mon, 21 Mar 2016 14:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ZsHM5yBK; dkim=pass (1536-bit key) header.d=taugh.com header.b=i9eOQilP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1URi596yK3Cu for ; Mon, 21 Mar 2016 14:13:49 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C859C12D8BE for ; Mon, 21 Mar 2016 14:13:48 -0700 (PDT) Received: (qmail 27767 invoked from network); 21 Mar 2016 21:13:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6c76.56f0640b.k1603; bh=jLFmi/rkg1i3T+zmnvA5jDbV32ei9w055s+jg8iFCrE=; b=ZsHM5yBKVMOPnp1jbsd9+8PfRtHXNteAixMNCJF3z+q/UYt4VjSl55WU0aRKRCShN8LdIUcGm1/CEvOCA1woQR1OUGqMnOzYar2Np+c4161DNCWDQykP8k+mzudhfSl6/Fxu72PhOMp1NVLihPBFlZZSNodTC19+RXCQHUSXVuhm1RD0vQ5YsArzO84CFFKeDNYUagGmZI81yJ/BpUZtZrH7FXRrmxciRYgj2WrsDs7vzk9Ylryxv0F3kIhszBDW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6c76.56f0640b.k1603; bh=jLFmi/rkg1i3T+zmnvA5jDbV32ei9w055s+jg8iFCrE=; b=i9eOQilPlwdCaR0amxZzBwERB2JdnXy08qDBbL+7KzkMsj2PLOEUzCwSdVu5bgqbIhVzvfpAQhBHyCiwAM02LKgdK7y/VaIf5Vwv4UI1MwJ8AmCiBGFd8b9uwxpAMTRIib/M/YNvQM2pdopTpztaoDrbyyEQIexNP63WNoWGES0H8uK8SofWSdLChXeGlMABVTCM+X/HJlFtzeP7qJJbgx0sRud19kDWZLjY0+eaHHXsDvFIZUe0iPVWFaAeFDT3 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 21 Mar 2016 21:13:47 -0000 Date: 21 Mar 2016 17:13:46 -0400 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <56EFD129.7050605@mozilla.org> <20160321161508.47873.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:13:50 -0000 > DNS resolvers retrieve and cache information on-demand when queried for it > by clients. That means there is still a penalty 1) for the initial and > subsequent cache misses and addtionally 2) for every lookup from > application to DNS resolver. Yes, but on any sort of reasonably busy system the cache will be on the same host or at worst a fast LAN hop away so it's pretty quick. Compare that to the cost of periodically sucking down and parsing and storing the text PSL and it seems pretty clear that which one is faster depends entirely on the application and details like how you store the parsed PSL. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Mar 21 14:39:02 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53212D0B8 for ; Mon, 21 Mar 2016 14:39:01 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwPFuRH3TErh for ; Mon, 21 Mar 2016 14:38:59 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFB012DA92 for ; Mon, 21 Mar 2016 14:38:09 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id kc10so77721807igb.0 for ; Mon, 21 Mar 2016 14:38:09 -0700 (PDT) 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; bh=1sFh4MlKDBZpM1NMDo2FWxu9lM/ra9UdTIJayU4oVOw=; b=HDGNCxXFmy+Gec6lhvFt5kE55WU/ZgU0myxTx8fU9pgwxK+au2BQgsIbQ1Ihk0GeKC hxrnBayQmGiMtS+RddNx3Eco8w6qkLLJ6dyJNqteEYYrsveWX7jtdMp3ODipOBha3h+p 8ucDGgJgwqOirjco7GYn96/fnMVuFkR0569YU= 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; bh=1sFh4MlKDBZpM1NMDo2FWxu9lM/ra9UdTIJayU4oVOw=; b=YJRbBi6NIKp+JmcPK6wR/CjiqgmmIGBSQfPbx+QCDn3o+lU6/iXGK9DZdw81T/NDv+ Yb9yVz6sXrkaEWxH9rMFl1NB/loWNxrROzM8vXhPvBfBOZOXC4fvx7Z2qJP5/ueUcwe3 LhPJUn6/ZXVo0y066IO7AXvnOB7DGFSIPzbmMTTrwemqqyYbj9kwuHNlr2ilBlGdpJVH Ianyk+hXbrYSKkTnPP/5PjMljwly5kt7oKxH7RvZ1jIC5Vddk8WNGDwxL6tkWVtzVgfA s7/nfYLUkuQlUiSkdinl9MB4hbaZqpWWbf/dIr/XmE6QR0S1ALf52u//CEj8rA1ASiKf bXAA== X-Gm-Message-State: AD7BkJKuHYRcvpPx8LQZxf2sbsbJwUepXDd1nZ7wMIUNCDiikq+uRRUzRm2JXvaUkaTB1esxVjJAw5mH7uy0XA== MIME-Version: 1.0 X-Received: by 10.51.17.4 with SMTP id ga4mr15147457igd.88.1458596288298; Mon, 21 Mar 2016 14:38:08 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.201.16 with HTTP; Mon, 21 Mar 2016 14:38:08 -0700 (PDT) In-Reply-To: References: <56EFD129.7050605@mozilla.org> <20160321161508.47873.qmail@ary.lan> Date: Mon, 21 Mar 2016 14:38:08 -0700 X-Google-Sender-Auth: XXyCiaXZgBjHQYmwLIhCv9mzRj8 Message-ID: From: "Kurt Andersen (b)" To: John R Levine Content-Type: multipart/alternative; boundary=001a1134b422a2bf18052e95e9d2 Archived-At: Cc: Casey Deccio , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:39:01 -0000 --001a1134b422a2bf18052e95e9d2 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 2:13 PM, John R Levine wrote: > DNS resolvers retrieve and cache information on-demand when queried for it >> by clients. That means there is still a penalty 1) for the initial and >> subsequent cache misses and addtionally 2) for every lookup from >> application to DNS resolver. >> > > Yes, but on any sort of reasonably busy system the cache will be on the > same host or at worst a fast LAN hop away so it's pretty quick. Compare > that to the cost of periodically sucking down and parsing and storing the > text PSL and it seems pretty clear that which one is faster depends > entirely on the application and details like how you store the parsed PSL. > There have also been some assertions in past F2F discussions about some value in supporting off-line cases to determine boundaries, though I am unconvinced that is a use case that we should worry about. --Kurt Andersen --001a1134b422a2bf18052e95e9d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 21, 2016 at 2:13 PM, John R Levine <johnl@taugh.com> w= rote:
DNS resolvers retrieve and cache information on-demand when queried for it<= br> by clients.=C2=A0 That means there is still a penalty 1) for the initial an= d
subsequent cache misses and addtionally 2) for every lookup from
application to DNS resolver.

 Yes, but on any sort of reasonably busy system the cache will be on the sam= e host or at worst a fast LAN hop away so it's pretty quick.=C2=A0 Comp= are that to the cost of periodically sucking down and parsing and storing t= he text PSL and it seems pretty clear that which one is faster depends enti= rely on the application and details like how you store the parsed PSL.
<= /blockquote>

There have also been some assertions in pas= t F2F discussions about some value in supporting off-line cases to determin= e boundaries, though I am unconvinced that is a use case that we should wor= ry about.

--Kurt Andersen=C2=A0
<= /div> --001a1134b422a2bf18052e95e9d2-- From nobody Mon Mar 21 14:39:15 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB5A12D095 for ; Mon, 21 Mar 2016 14:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLF6oG1wh3EC for ; Mon, 21 Mar 2016 14:39:09 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B1312D098 for ; Mon, 21 Mar 2016 14:38:24 -0700 (PDT) Received: (qmail 32434 invoked from network); 21 Mar 2016 21:38:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Mar 2016 21:38:23 -0000 Date: 21 Mar 2016 21:38:01 -0000 Message-ID: <20160321213801.48714.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: johnl@taugh.com Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:39:13 -0000 >> DNS resolvers retrieve and cache information on-demand when queried for it >> by clients. That means there is still a penalty 1) for the initial and >> subsequent cache misses and addtionally 2) for every lookup from >> application to DNS resolver. More to the point, self-publishing in the DNS has different semantics from third-party publishing by someone like Mozilla. I think the people at Mozilla are doing a good job at a thankless task, but self-publishing has a lot to recommend it. R's, JOhn From nobody Mon Mar 21 14:50:20 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7E12D0AC for ; Mon, 21 Mar 2016 14:50:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeWbg-tqOo5x for ; Mon, 21 Mar 2016 14:50:16 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394CE12D0A1 for ; Mon, 21 Mar 2016 14:50:13 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l68so127879213wml.0 for ; Mon, 21 Mar 2016 14:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WNG6rHRCN1by8AQHtB1OgyA7M052D/Kfad1/Dpgk8Rc=; b=XtsCFhVVLZFTElc7HdLPGpqDwu8I5DRVaxw5VPbhZUAJ0VzUMAe0yDS4ADC8XHdgB+ IBN2V4Nzr1UBPXOoIHPE1PZCWiVrDagK3HJmaHHh77OfA/XqmPNwJJo2Z8l/Vn3Mi40j gAt3kRRG8K/NiSn7/1VJYZL8wU0oU/awrK/zA= 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; bh=WNG6rHRCN1by8AQHtB1OgyA7M052D/Kfad1/Dpgk8Rc=; b=YVQBZKxkxdptYDnOZpXqOUpp3K59taKDQXMI07gxL4eHQVDLZOBRlOhXKdLQe+jsri zWvKZTYxFSYupGMn+TCamlQ8smugqPcZ7i4r6udxiCoo6n68P0ydI0paZBbdZyBVRuzQ GVrYCRViuFSN2GhWiDJukBSn64pHQc53af9xR2d7mAZIyrew8HY91K6FVT/AqBKkyAVI 24nbGYdSO77/x7HXPcILABBUlaeaXpBuAtojapj/lEQMXYKVSGrO1V0A0GPK0S86wBeU H0cansN2zs0HRsfIERsbysHkYVfLzI7vLO/BkZQ8tYyULR3ZI+yR2pYQz/44ICqixva7 3YKg== X-Gm-Message-State: AD7BkJJDaptIUUDR5EUdd1Cn33e1rLNGeKSoQD48Qx7dY2qc+8KHhe3kCI9qki2z8HUPqrRVerkWZwqo8f6zYw== MIME-Version: 1.0 X-Received: by 10.28.10.149 with SMTP id 143mr15530965wmk.38.1458597011803; Mon, 21 Mar 2016 14:50:11 -0700 (PDT) Received: by 10.194.9.170 with HTTP; Mon, 21 Mar 2016 14:50:11 -0700 (PDT) In-Reply-To: References: <56EFD129.7050605@mozilla.org> <20160321161508.47873.qmail@ary.lan> Date: Mon, 21 Mar 2016 17:50:11 -0400 Message-ID: From: Casey Deccio To: "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary=001a11444df0c26f1d052e96144f Archived-At: Cc: John R Levine , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:50:19 -0000 --001a11444df0c26f1d052e96144f Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 5:38 PM, Kurt Andersen (b) wrote: > > On Mon, Mar 21, 2016 at 2:13 PM, John R Levine wrote: > >> DNS resolvers retrieve and cache information on-demand when queried for it >>> by clients. That means there is still a penalty 1) for the initial and >>> subsequent cache misses and addtionally 2) for every lookup from >>> application to DNS resolver. >>> >> >> Yes, but on any sort of reasonably busy system the cache will be on the >> same host or at worst a fast LAN hop away so it's pretty quick. Compare >> that to the cost of periodically sucking down and parsing and storing the >> text PSL and it seems pretty clear that which one is faster depends >> entirely on the application and details like how you store the parsed PSL. >> > > There have also been some assertions in past F2F discussions about some > value in supporting off-line cases to determine boundaries, though I am > unconvinced that is a use case that we should worry about. > Please remember that offline usage is the status quo! It seems like a pretty big assumption that we need not worry about "offline cases" when that is our starting place. Casey --001a11444df0c26f1d052e96144f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 21, 2016 at 5:38 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:

On Mon, Ma= r 21, 2016 at 2:13 PM, John R Levine <johnl@taugh.com> wrote:<= br>
DNS resolvers retrieve and cache information on-demand when queried for it<= br> by clients.=C2=A0 That means there is still a penalty 1) for the initial an= d
subsequent cache misses and addtionally 2) for every lookup from
application to DNS resolver.

 Yes, but on any sort of reasonably busy system the cache will be on the sam= e host or at worst a fast LAN hop away so it's pretty quick.=C2=A0 Comp= are that to the cost of periodically sucking down and parsing and storing t= he text PSL and it seems pretty clear that which one is faster depends enti= rely on the application and details like how you store the parsed PSL.
<= /blockquote>

There have also been some assertions= in past F2F discussions about some value in supporting off-line cases to d= etermine boundaries, though I am unconvinced that is a use case that we sho= uld worry about.

Please remember that offline usage is the statu= s quo!=C2=A0 It seems like a pretty big assumption that we need not worry a= bout "offline cases" when that is our starting place.

Casey

--001a11444df0c26f1d052e96144f-- From nobody Tue Mar 22 01:09:14 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948AA12D113 for ; Tue, 22 Mar 2016 01:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUJ5IugQM1tU for ; Tue, 22 Mar 2016 01:09:10 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0116.outbound.protection.outlook.com [104.47.92.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E5F12D534 for ; Tue, 22 Mar 2016 01:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cVQUN2cPzAZ4hjqyidi3cNTOyL7WQ3vbcYeQDP0xt+Y=; b=vH9oV5ESR6RK3+VDaECnJV/ZWtNxdRMhB9KkqRivxShWc00o1XIocrNM/3LgckkJ03RQrXgXn5rH/L3/KHGr6Fuq6XzlrmrS8tF6et6DBcTJ/XVLQZvT2/vYEWuHyIlAtk10Kg7PZbdntgkHsQrErVAKMFUzIcIzQt3T71CTeqQ= Authentication-Results: cnnic.cn; dkim=none (message not signed) header.d=none;cnnic.cn; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 08:09:06 +0000 To: John Levine , References: <20160321024312.44325.qmail@ary.lan> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F0FDA2.9040100@it.aoyama.ac.jp> Date: Tue, 22 Mar 2016 17:09:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321024312.44325.qmail@ary.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0018.jpnprd01.prod.outlook.com (25.161.131.156) To TYXPR01MB0927.jpnprd01.prod.outlook.com (25.168.45.22) X-MS-Office365-Filtering-Correlation-Id: a91292ae-783d-445a-33ad-08d352293d20 X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 2:tS6NQzRJaOG3V9YtrUK1BxoJWkg1k6xHe2G0GyJCri4O6o0O1+N9lwasVnOYY3qOrps9U8bD9A2JKlStyG9oGAopDyHh4oejTNIc4LJum75oLNZGazVzvBQD2sC6SmFOcX+aOk/+kNeHGPUbSj59KHegD+hrTsE6AcLQvtfaBDft0aKuvstk4GP/S7LjJgQy; 3:GngGrp1m2yvCX1+Io2/ja2c5EC6kHImc3beGnsR1I9OCHpsaF4Hl0b35JGCborYB31o02V5ovQ6jZEb69+Ea8a5b/Bn519dm6m/wWDfZlU4XNc2bMSyb2HavakgS4yms X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 25:VYjeyO2og6roOnGBGJ+qEq9w8i9La1Bq39OU1UWl3hYlv0VxZ/gv6W9mATk4b+aYFd7PwvnMg5mnXJRhCLY5CMutgA40i/NMpX445kQVJ148D+T7pSarumxc182HeSpDBM9DiIGTXvjRhTnLX/u4/LJcY4x77/1x7/gmaw9qOTG0+CwNWZrT9KaC57ks5z5YC3KvTtPA3CvBCIBS5IeBg0Wa9gDgQXM0zw79uzBFxGlhdgY+C6JVCeUuYSLjC065Q/i/y9be0TtdD5eQswE/NUd8TyvFc2kUJ2/z7YIjK8cGwElpNDj5Yq+oEvxbIymgCZ6vgMpsJfumaQcdpmFOr6vXvVTcYtbsT6H26hsIw5uOZbIXJTSrwU8X2It/APVXLKhuqPgCyBNKnW3G10EP8ZMjgrEEhvybBHYJBC9d3dCW6uuXeSE9Eps5qzIvGbFmp16Vtsn40YobM1PypCL23/UHbov/pdrBEl/M3Mx9Y4L/zZGMlFqpNyNgfAolqKES4OltfoX0B7DgRCmbweQadI5bXBUKuyYQPikXg0/VSCoHJiH/y9rMfbt0WagCu4UgfHD01on5lgYDSFtc3XXSwllY5+FZmcFdPQ4AiI7+vJfAMSWByy5CnyStB4mO2JCGcu8ahVftLRZkVbx8E7ukgg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6042046)(6043046); SRVR:TYXPR01MB0927; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 4:s2uHwdOrLcZFbC+jDZ9nZDEK19PFJjuV6MzRadORZaKxGX+u55VCPAYstbkcViOlhvUGNlY9eWtIO0WdjGmCEVI55zs4MS9NC4Yo4dhmnDuUiBWP7l4hVPvknxqk6OykBd3WcP5Gy1GWOrOkJnaHWCgg+2pPmXN0CEkZnbdjP7MOrNB/TrizWGstw1HfWQ35PK1xHnhRsH7H2xoFPF653EARVMPa9rntyuKdw1OjBwB43SfK5LiBINaMmOzVcPOtwj5VcokdBj97qA574pX3bn7GZgeBzrI5JjAmWxECgbi8dPTgjwlmaNdBA5WJ94D4r4tvETAQC1E7s6+P6X97cPrktZFozJd1Tvw6g/GSaXY0EWgpyk5eHHkE+J+tmdtGWrdk0yb6Dp7cyNTcW+ZlM5wEztf6lVo5aLDkV7ZDkBs= X-Forefront-PRVS: 08897B549D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(1096002)(6116002)(586003)(3846002)(59896002)(77096005)(2950100001)(5004730100002)(15975445007)(76176999)(33656002)(5008740100001)(92566002)(2906002)(81166005)(2870700001)(4326007)(23676002)(54356999)(64126003)(65956001)(66066001)(65806001)(83506001)(19580395003)(50466002)(86362001)(47776003)(189998001)(50986999)(42186005)(87266999)(65816999)(4001350100001)(5001770100001)(74482002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0927; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI3OzIzOkMrYVQzYXN2bTAzeXNQQ25TTzM2QUo4Qzdh?= =?utf-8?B?U010RDltNWhxYmxNbmVwckdBeVlSc3ZrVHlucXBNWjJVdWY3cENrMWlETTBh?= =?utf-8?B?bllILzZDdGJiQ3dqODdLaExKd0dKZVpHYXg1NnpYRzlwZ1ovUDNIdjZRQWc4?= =?utf-8?B?dWFaTFByV1BqV0I2ZFB4L2xCcWs1dklsTW0wSEJPdUlwalo4b3lSK2s4NEM1?= =?utf-8?B?dGl1ZUdDS1dDYzVFeTJmTUpwell6VzhndlJFaDhURUJQdGVZc3FsdUFYR0ZH?= =?utf-8?B?dWxnb3FpRllyWVRkQ2l0OXRwOVNwNVphcVhveUFKaWlEUWc1UVlyRmpYSEpN?= =?utf-8?B?M2Eyb2dHSGxDWGVuc0VkZ0ZOTjFkRUZpZjV2Tm1vK3FMMzg2czlXbThmY3Fl?= =?utf-8?B?cGdyZ2hmb00wNjFRVFZ2cmw0bU5tYW5mTkZDMmFpMHdsRlk3dmRwRXU3eHFz?= =?utf-8?B?cGNoTUxOaE85UXpiWVMxeTR3SXhvcmt0MVJGUkdXM1J0cHA3Ujc3cDlGNVRk?= =?utf-8?B?S3Y5SXdvNWVINUNUWVBFR0RjMHppaGtZSlA1QlNZOUJFbHgwcEoxclpFTDlO?= =?utf-8?B?SUQ0QS90Sis2S0Nab1l2Z1p6MHErNEsvc09FcUFQaG4wZEVTM1YxRUVBcEFH?= =?utf-8?B?QUtkaGZQTEZWTmNwUi9tQVpTalhSaTJlNE9UWm5FQTVTRUlwTXVMcEdPQ29G?= =?utf-8?B?VU5UelMrM3E0eFBVWGJXV283WXlGREVtUGRZbkZ0Y3Fad3Z2MGc5S3Jaa0tt?= =?utf-8?B?MWdvNFFwV3ltUVg5MytaWEZVQ094K0hkRHozUi8wWGdpMTl0QStiLzIyOGRU?= =?utf-8?B?aWNQeWxzeFBDUEMxYnhoTGFEdXdBd3NwVXZlanF5blgzQzh2YmE3Q293U2dY?= =?utf-8?B?b3Z6Um95QnBrSWZyYm9BdHcwUko1OVN0b1dwTXNCVjFLbmFsMVRKYy9NdFNY?= =?utf-8?B?RVVKN2hwY3hPT3M4NW5NOXV3MW1WL052N2lKaWlBd2hBMng3OW83M0NPMzBT?= =?utf-8?B?djAyUllmcHdhcFhTOEVMcHlwNldmd08reVpTOXY1MmlVVTZ5R1V6M0pBMlJS?= =?utf-8?B?bDdOMEJDamY3YVJiSVBqTDBvSUZqcWpBNzljTWdrZUZPRWtoSENyNWdlbXdX?= =?utf-8?B?U09mNlJXRW1VQlFkVWtrZVMwaDhVRnlTT2pSYVVvL2d5ZGNxbG9KTDdrbjM2?= =?utf-8?B?UTdmUW93a29ENGNpQjAycUxSN2VNN2lSZnFIYkZ4RlFkN0VtR205dVQvMTdz?= =?utf-8?B?TEswRWhHVERld0htcGxROWIrMXd0c1BCVTQxUnE4SlJ3Zkx6T0hRV1MrYmhp?= =?utf-8?B?WG5zc1JKaklnZWRRTmRVeVRhS3ZtbDE3cHQvNTFnMTdGYkk4TytFdVROVEpw?= =?utf-8?B?bzZTQ0hjN0ZaeVRZWEh0b0hxNlVqalpoM3hMYTJyanpBTFRWRDQwNU1wVFBz?= =?utf-8?B?eEVhYlVLNm1Sd0JUZ0x3aWFURjA4YnZmUVliUmczT0cwdnlQbUxNbjRuRUdp?= =?utf-8?B?NEd2UT09?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 5:PLfpG0z6F+3z41K3QnsNq+noiE5E/rIIo5TEdM61un67x6+KRo+l5sd1RCcowlZ/ihyTRMIbJcq8gKIahZn47vCjjlfToou+FmvSWZuq/Ct95u5n8pe9kE5cosDi39wMquIamYzEx8iYPUY1fQhTNw==; 24:Li9qYHLkFUNISuJ26dflTFE3gbGS/YW4OLhI9m7kBX/PvzNqIRePyqMXXSgI2w0t7rZC0ZkvNYJVOvZymfUMhL/CoLWd8n6wTbuoJPDDvks= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2016 08:09:06.1404 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0927 Archived-At: Cc: yaojk@cnnic.cn Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 08:09:12 -0000 On 2016/03/21 11:43, John Levine wrote: > For the parallel subtrees, I'm wondering whether the points of > relation are all at the TLD and if so, some limited kludge would do > the trick. Hmmn. I also wonder how important it is in both cases to > handle relationships among more than two trees. For example. the Indian > ccTLD controls .in .ভারত .భారత్ .ભારત .भारत .بھارت‎ .ਭਾਰਤ and .இந்தியா. > I don't know whether they're all supposed to be equivalent or whether there > are separate registrations in each. They are different scripts, used for different languages in India. Although I don't know what exact policy will be applied, it wouldn't make much sense to have e.g. an Arabic-script (Urdu language) second-level name after the Tamil TLD (.இந்தியா), and so on. So definitely the subtrees won't be the same, and the chance that the same second-level label turns up in multiple subtrees seems slim. Also, as https://www.registry.in/Internationalized_Domain_Names_IDNs indicates, these TLDs seem to be activated in a staged fashion, with .भारत (Devanagari Script, used for Hindi, India's most popular native language) being first. So at least for some time, there won't be any equivalents on the second level, either. What may happen, for some of the second levels, is that the parallelism between the Indic scripts is used. This is already the case for these TLDs, in that four of them ( भारत, Hindi, U+092D 093E 0930 0924; ভারত, Bengali, U+09AD 09BE 09B0 09A4 ਭਾਰਤ, Gurmukhi, U+0A2D 0A3E 0A30 0A24; ભારત, Gujarati, U+0AAD 0ABE 0AB0 0AA4, see http://www.iana.org/reports/2011/india-report-07jan2011.html for additional detials) are exact parallels of each other (with hex 80 offsets), and a fifth, భారత్, Telugu, U+0C2D 0C3E 0C30 0C24 *0C4D*, is very close but needs a final vowel killer sign. The remaining two, Arabic (completely different encoding) and Tamil (completely different language family, and therefore in this case using a different word) differ. So similar relationships may hold at the second level, with the equivalent second level names using the script of the TLD, but in many (but not all) cases using codepoints with equal offsets. It will be interesting to see how registry.in handles the assignments of second level labels in the other ITLDs (besides भारत). For भारत, they seem to favor trade mark holders over holders of ASCII domain names in .in, and they might do something similar for the other TLDs (adding .भारत to .in). A lot of script parallelism may already exist for trade marks themselves. In addition, if actually deployed (and not just used as an alias for an English or Hindi version of a site), it's very easy to guess that the actual content of each second-level domain would be in the language(s) that are written in that script, even if their content is (mostly) the same. Regards, Martin. From nobody Thu Mar 24 20:19:53 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4597912D895 for ; Wed, 23 Mar 2016 17:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLym8iUcPdeJ for ; Wed, 23 Mar 2016 17:24:09 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F04912D8C2 for ; Wed, 23 Mar 2016 17:24:09 -0700 (PDT) Received: from [10.32.60.84] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2O0O7AE026353 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Mar 2016 17:24:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.84] From: "Paul Hoffman" To: "dbound@ietf.org" Date: Wed, 23 Mar 2016 17:24:07 -0700 Message-ID: In-Reply-To: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 20:19:51 -0700 Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 00:24:11 -0000 Here is a hopefully-useful view: - There is a current solution that solves most of the problem space. It is managed by "volunteers" and works OK. - The WG has seen two new proposed solutions that solve some more of the problem space. Both allow management by individual zone owners. - If the WG closes without standardizing on one of the proposed new solutions, the highest risk is that the volunteers running the current solution stop. The world also loses the extra problem space coverage, but that doesn't seem to be so significant to the world. - If one or both proposed solutions is deployed in addition to the current solution, the highest risk is that relying parties looking at multiple sources will get differing answers and won't know which to trust. - There doesn't seem to be much interest in the new solutions from other than their respective authors. That is, we haven't seen much sign from the relying parties or their surrogates saying "we really need the bigger problem space" nor "we need to get the information in a different way". Personally, I am mostly concerned with relying parties getting conflicting information, and that seems inherent in any transition from the current solution to either of the proposed ones (or, worse, to both of the proposed ones at the same time). --Paul Hoffman From nobody Fri Mar 25 18:03:16 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8E12D0E5 for ; Fri, 25 Mar 2016 18:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_biVw8TimDC for ; Fri, 25 Mar 2016 18:03:12 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7812D105 for ; Fri, 25 Mar 2016 18:03:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id CB13010AF4 for ; Sat, 26 Mar 2016 01:03:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWFC0Gnh3imz for ; Sat, 26 Mar 2016 01:03:10 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 1934B10ACE for ; Sat, 26 Mar 2016 01:03:10 +0000 (UTC) Date: Fri, 25 Mar 2016 21:03:08 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326010308.GH5239@mx2.yitter.info> References: <2016032110114814858510@cnnic.cn> <20160321024312.44325.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160321024312.44325.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:03:15 -0000 On Mon, Mar 21, 2016 at 02:43:12AM -0000, John Levine wrote: > For the parallel subtrees, I'm wondering whether the points of > relation are all at the TLD No; indeed, your mail contained an example of how not. Those other cases are, IMO, actually considerably more important. I will note that _none_ of the proposals really solves the parallel subtrees case in its full implications. A very early version of the proposal I've written had some hints about how to achieve that, but I pulled it out. Part of the reason I did was because it was inadequate, because > ccTLD controls .in .ভারত .భారత్ .ભારત .भारत .بھارت‎ .ਭਾਰਤ and .இந்தியா. of things like that. What you really need to make sensible registry policy decisions is the blocked/allocatable/allocated/delegated data that is implicit in the LGR (and lager) work. The natural place to have gotten that would have been RDAP whenever it made sense, which was why I thought an SRV entry or something would have been nicer than the IANA registry we ended up with (since those won't scale). I'd like to think that example is a cautionary tale about trying to do too little, but I don't expect we'll take it that way. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 25 18:16:15 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812FA12D0FB for ; Fri, 25 Mar 2016 18:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_sjsY8OWXBi for ; Fri, 25 Mar 2016 18:16:10 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 512B612D0AE for ; Fri, 25 Mar 2016 18:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id DDC0710AF3 for ; Sat, 26 Mar 2016 01:16:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx6xcaI1uuxB for ; Sat, 26 Mar 2016 01:16:09 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 145F510ACE for ; Sat, 26 Mar 2016 01:16:09 +0000 (UTC) Date: Fri, 25 Mar 2016 21:16:07 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326011607.GI5239@mx2.yitter.info> References: <20160320003953.39721.qmail@ary.lan> <56EFD129.7050605@mozilla.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EFD129.7050605@mozilla.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:16:13 -0000 On Mon, Mar 21, 2016 at 10:47:05AM +0000, Gervase Markham wrote: > Perhaps a design goal of the new system (and I don't know which, if any > drafts, meet this goal) would be the ability to somehow scan the live > information across the entire Internet and re-construct the PSL on a > regular basis for those applications for which regular network lookups > are too costly? That very analysis is behind some of the interations of the proposal that Jeff and I have made. The basic idea is that a PSL-style list is going to be a permanent feature, because even one additional lookup at resolution time for interactive users (e.g. web browsers) will always be a non-starter. The idea behind the SOPA record is that such lists then become self-maintaining. You get an initial static one when you install a browser. It is presumably bootstrapped by using the PSL and then checking the PSL against what's in the DNS. Over time, browsers and other tools can do the SOPA lookups opportunistically and in the background, according to the sites the user frequents. There are multiple benefits from this: 1. The maintenance of the information comes to be better aligned with the actual operators of the zones. 2. Corrections do not depend on the PSL update cycle + the browser update cycle, but become available almost as soon as some user visits a site. 3. (Maybe 2.a.) The maintenance of the PSL can become fully distributed the way the DNS is. 4. New, more sophisticated policies within sites become possible that were not possible before. (4) is a long-term happy story, not a short term one, but I think it is a feature that provides a virtuous circle that allows the new properties to become available. 1-3 are the short term features that allow incremental deployment. We've tried to make this clear in the draft, but I guess it isn't or the questions wouldn't persist. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 25 18:27:05 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304DA12D0E5 for ; Fri, 25 Mar 2016 18:27:04 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywJs91YdIFqW for ; Fri, 25 Mar 2016 18:27:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0412D09C for ; Fri, 25 Mar 2016 18:27:01 -0700 (PDT) Received: from [192.168.1.111] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 093924771B; Fri, 25 Mar 2016 21:27:01 -0400 (EDT) From: "Marc Blanchet" To: "Andrew Sullivan" Date: Fri, 25 Mar 2016 21:27:00 -0400 Message-ID: <6C00E4F0-DEB6-4C10-81E6-12B5F3828BCD@viagenie.ca> In-Reply-To: <20160326011607.GI5239@mx2.yitter.info> References: <20160320003953.39721.qmail@ary.lan> <56EFD129.7050605@mozilla.org> <20160326011607.GI5239@mx2.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_104492BE-522D-4E32-9351-DF80A4543696_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:27:04 -0000 --=_MailMate_104492BE-522D-4E32-9351-DF80A4543696_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 25 Mar 2016, at 21:16, Andrew Sullivan wrote: > On Mon, Mar 21, 2016 at 10:47:05AM +0000, Gervase Markham wrote: >> Perhaps a design goal of the new system (and I don't know which, if >> any >> drafts, meet this goal) would be the ability to somehow scan the live >> information across the entire Internet and re-construct the PSL on a >> regular basis for those applications for which regular network >> lookups >> are too costly? > > That very analysis is behind some of the interations of the proposal > that Jeff and I have made. > > The basic idea is that a PSL-style list is going to be a permanent > feature, because even one additional lookup at resolution time for > interactive users (e.g. web browsers) will always be a non-starter. > > The idea behind the SOPA record is that such lists then become > self-maintaining. I’m sympathic to this solution, but as you may remember, we could have chosen a DNS new RR for RDAP and people were against because it means updating software (and also limited sandboxing in javascript browser environment) and nobody believe it would be done or deployed. I think we both agree that an in-DNS solution was better for RDAP and could be the best for dbound. So I’m asking the same question we had for RDAP: while an in-DNS a good solution, does it have the problem of finally not being implemented/deployed because of a new RR? Marc. > You get an initial static one when you install a > browser. It is presumably bootstrapped by using the PSL and then > checking the PSL against what's in the DNS. > > Over time, browsers and other tools can do the SOPA lookups > opportunistically and in the background, according to the sites the > user frequents. There are multiple benefits from this: > > 1. The maintenance of the information comes to be better aligned > with the actual operators of the zones. > > 2. Corrections do not depend on the PSL update cycle + the > browser update cycle, but become available almost as soon as some > user visits a site. > > 3. (Maybe 2.a.) The maintenance of the PSL can become fully > distributed the way the DNS is. > > 4. New, more sophisticated policies within sites become possible > that were not possible before. > > (4) is a long-term happy story, not a short term one, but I think it > is a feature that provides a virtuous circle that allows the new > properties to become available. 1-3 are the short term features that > allow incremental deployment. > > We've tried to make this clear in the draft, but I guess it isn't or > the questions wouldn't persist. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound --=_MailMate_104492BE-522D-4E32-9351-DF80A4543696_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 25 Mar 2016, at 21:16, Andrew Sullivan wrote:

On Mon, Mar 21, 2016 at 10:47:05AM +0000, Gervase Markham= wrote:

Perhaps a design goal of the new system (and I don't know= which, if any
drafts, meet this goal) would be the ability to somehow scan the live
= information across the entire Internet and re-construct the PSL on a
regular basis for those applications for which regular network lookups are too costly?

That very analysis is behind some of the interations of t= he proposal
that Jeff and I have made.

The basic idea is that a PSL-style list is going to be a = permanent
feature, because even one additional lookup at resolution time for
interactive users (e.g. web browsers) will always be a non-starter.

The idea behind the SOPA record is that such lists then b= ecome
self-maintaining.

I=E2=80=99m sympathic to this solution, but as you may re= member, we could have chosen a DNS new RR for RDAP and people were agains= t because it means updating software (and also limited sandboxing in java= script browser environment) and nobody believe it would be done or deploy= ed. I think we both agree that an in-DNS solution was better for RDAP and= could be the best for dbound. So I=E2=80=99m asking the same question w= e had for RDAP: while an in-DNS a good solution, does it have the problem= of finally not being implemented/deployed because of a new RR?

Marc.

You get an initial static one when you install a
browser. It is presumably bootstrapped by using the PSL and then
checking the PSL against what's in the DNS.

Over time, browsers and other tools can do the SOPA looku= ps
opportunistically and in the background, according to the sites the
user frequents. There are multiple benefits from this:

1.  The maintenance of the information comes to be better alig=
ned
with the actual operators of the zones.

2.  Corrections do not depend on the PSL update cycle + the
browser update cycle, but become available almost as soon as some
user visits a site.

3.  (Maybe 2.a.) The maintenance of the PSL can become fully
distributed the way the DNS is.

4.  New, more sophisticated policies within sites become possible
that were not possible before.

(4) is a long-term happy story, not a short term one, but= I think it
is a feature that provides a virtuous circle that allows the new
properties to become available. 1-3 are the short term features that
= allow incremental deployment.

We've tried to make this clear in the draft, but I guess = it isn't or
the questions wouldn't persist.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

dbound mailing list
dbound@ietf.org
https://www.ietf= =2Eorg/mailman/listinfo/dbound

--=_MailMate_104492BE-522D-4E32-9351-DF80A4543696_=-- From nobody Fri Mar 25 18:28:54 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442A412D0DD for ; Fri, 25 Mar 2016 18:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkIk77iYIiyW for ; Fri, 25 Mar 2016 18:28:51 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 9033B12D09C for ; Fri, 25 Mar 2016 18:28:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 4A2E310AF6 for ; Sat, 26 Mar 2016 01:28:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5Iu7Fftsk9e for ; Sat, 26 Mar 2016 01:28:50 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 9806A10AF4 for ; Sat, 26 Mar 2016 01:28:50 +0000 (UTC) Date: Fri, 25 Mar 2016 21:28:49 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326012849.GJ5239@mx2.yitter.info> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> 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: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:28:53 -0000 On Wed, Mar 23, 2016 at 05:24:07PM -0700, Paul Hoffman wrote: > Personally, I am mostly concerned with relying parties getting conflicting > information, and that seems inherent in any transition from the current > solution to either of the proposed ones (or, worse, to both of the proposed > ones at the same time). But part of the problem is that the existing system often gets things _wrong_, which is one of the things that caused me to start work on this in the first place (and which has been pointed out in every version of the drafts -- first that I put together and that Jeff and I then put together). There have been names in the PSL list that don't accurately reflect the registry (i.e. zone operator) policy for how that name worked. For instance, there were at one time several museum names on there that were actually empty non-terminals and not suffixes of any kind. Closer to home for me, there were names on the PSL that Dyn (my employer) hadn't used in some time for delegation (since fixed, I believe). This is not to criticise anyone, but instead to make the same point I've been making for some years now: if you want to make assertions about names in the DNS, then the place to make those assertions is in the DNS, both so that you get the semantics right automatically and so that when the DNS-administrative boundaries change, the people who have the authority to make the assertions needed are the people actually in control of the domain name. That's the reason this WG was chartered in the first place, I think, and the problem is still with us. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 25 18:43:08 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C6112D587 for ; Fri, 25 Mar 2016 18:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80XTsBaDLSoH for ; Fri, 25 Mar 2016 18:43:06 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 0614512D09C for ; Fri, 25 Mar 2016 18:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id D6FA010AD0 for ; Sat, 26 Mar 2016 01:43:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jntFpTh0N9Qs for ; Sat, 26 Mar 2016 01:43:04 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 1E76F10ACE for ; Sat, 26 Mar 2016 01:43:04 +0000 (UTC) Date: Fri, 25 Mar 2016 21:43:02 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326014302.GK5239@mx2.yitter.info> References: <20160320003953.39721.qmail@ary.lan> <56EFD129.7050605@mozilla.org> <20160326011607.GI5239@mx2.yitter.info> <6C00E4F0-DEB6-4C10-81E6-12B5F3828BCD@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C00E4F0-DEB6-4C10-81E6-12B5F3828BCD@viagenie.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:43:07 -0000 On Fri, Mar 25, 2016 at 09:27:00PM -0400, Marc Blanchet wrote: > in-DNS a good solution, does it have the problem of finally not being > implemented/deployed because of a new RR? The difference between RDAP and SOPA has to do with the incentives for deployment. (The RDAP case could in fact have been solved by SRV, if you ask me, but it was quite clear that the WG didn't want to do it.) The SOPA draft defines the default case as, "Nobody is in the same policy realm as me." For a large number of sites, this is exactly the right answer. The SOPA draft says you can make the explicit claim, "Nobody is in the same policy realm as me." That has certain advantages, such as caching and so on, which means that it's the right answer for public suffixes. Since they're the people who have the greatest potential to deploy new RRs, there's a positive effect. The SOPA draft gives you a way to make more significant statements about others being in the same policy realm. There is a barrier to new RRs here, but there are mitigating factors: (1) the sites that want this sort of functionality are more sophisticated, so they are the more likely to be able to deploy new RRs; (2) the lookup story doesn't need to be perfect for consumer-end hosts, because of the plan to fall back to browser-distributed files as well (which now get the benefit of automatic crowdsourced maintenance); (3) an important part of this story is the CA checking when issuing certs, which benefits from the new RR even if consumer-end hosts. Finally, I do, very much, think that things like SOPA would be way easier to deploy if we did something like John's RRTYPE pattern-classification stuff. That has kind of gone nowhere, but partly because the demand is stanched by the constant refrain that new RRs are impossible to deploy. I'd be prepared to update the SOPA draft with a normative dependency on draft-levine-dnsextlang-07 if we think it would help. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 25 19:57:19 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0C12D1D9 for ; Fri, 25 Mar 2016 19:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv0OZqr6RMFx for ; Fri, 25 Mar 2016 19:57:15 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2E312D0F2 for ; Fri, 25 Mar 2016 19:57:14 -0700 (PDT) Received: (qmail 79552 invoked from network); 26 Mar 2016 02:57:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 26 Mar 2016 02:57:14 -0000 Date: 26 Mar 2016 02:56:52 -0000 Message-ID: <20160326025652.14512.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <6C00E4F0-DEB6-4C10-81E6-12B5F3828BCD@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: marc.blanchet@viagenie.ca Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 02:57:16 -0000 >best for dbound. So I’m asking the same question we had for RDAP: >while an in-DNS a good solution, does it have the problem of finally not >being implemented/deployed because of a new RR? Both my proposal and Casey's uses a distinctive tag in the DNS names, so they could both work either with a new RRTYPE or using TXT records. SOPA needs a new RRTYPE. R's, John From nobody Fri Mar 25 20:02:51 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0BD12D12C for ; Fri, 25 Mar 2016 20:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTJiyHCFcypS for ; Fri, 25 Mar 2016 20:02:45 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7812D0E6 for ; Fri, 25 Mar 2016 20:02:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6894210AF3 for ; Sat, 26 Mar 2016 03:02:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id detfzpkVhiMl for ; Sat, 26 Mar 2016 03:02:43 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 840E110AB6 for ; Sat, 26 Mar 2016 03:02:43 +0000 (UTC) Date: Fri, 25 Mar 2016 23:02:41 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326030241.GO5239@mx2.yitter.info> References: <6C00E4F0-DEB6-4C10-81E6-12B5F3828BCD@viagenie.ca> <20160326025652.14512.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160326025652.14512.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 03:02:48 -0000 On Sat, Mar 26, 2016 at 02:56:52AM -0000, John Levine wrote: > Both my proposal and Casey's uses a distinctive tag in the DNS names, > so they could both work either with a new RRTYPE or using TXT records. Yes. And as a result, they can't make claims about that owner name itself. This point is made in the SOPA draft. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 25 22:00:13 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206E612D144 for ; Fri, 25 Mar 2016 19:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT-_-wqAC-85 for ; Fri, 25 Mar 2016 19:10:07 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92F812D141 for ; Fri, 25 Mar 2016 19:10:07 -0700 (PDT) Received: from [10.32.60.62] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2Q2A4AY028568 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2016 19:10:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.62] From: "Paul Hoffman" To: "Andrew Sullivan" Date: Fri, 25 Mar 2016 19:10:04 -0700 Message-ID: <2E198AB2-416D-4DF6-A6EB-010D407E2D20@vpnc.org> In-Reply-To: <20160326012849.GJ5239@mx2.yitter.info> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <20160326012849.GJ5239@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Fri, 25 Mar 2016 21:59:54 -0700 Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 02:10:09 -0000 On 25 Mar 2016, at 18:28, Andrew Sullivan wrote: > On Wed, Mar 23, 2016 at 05:24:07PM -0700, Paul Hoffman wrote: >> Personally, I am mostly concerned with relying parties getting >> conflicting >> information, and that seems inherent in any transition from the >> current >> solution to either of the proposed ones (or, worse, to both of the >> proposed >> ones at the same time). > > But part of the problem is that the existing system often gets things > _wrong_, We fully agree here. I even agree with the placement of your proposed solution: in the DNS, where the administration actually happens. However, that doesn't negate my concern: when the second solution is (slowly) ramping up, there will be two sources of information, and the older one will be much fuller (even if some of that fullness is wrong). My response in this thread was "on moving forwards", not "on how to move differently". --Paul Hoffman From nobody Sat Mar 26 06:01:50 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107E312D5AD for ; Sat, 26 Mar 2016 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwpIDHq0zdr1 for ; Sat, 26 Mar 2016 06:01:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6E12D1B6 for ; Sat, 26 Mar 2016 06:01:47 -0700 (PDT) Received: from [192.168.1.111] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0254A4771B; Sat, 26 Mar 2016 09:01:46 -0400 (EDT) From: "Marc Blanchet" To: "John Levine" Date: Sat, 26 Mar 2016 09:01:46 -0400 Message-ID: <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> In-Reply-To: <20160326025652.14512.qmail@ary.lan> References: <20160326025652.14512.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 13:01:49 -0000 On 25 Mar 2016, at 22:56, John Levine wrote: >> best for dbound. So I’m asking the same question we had for RDAP: >> while an in-DNS a good solution, does it have the problem of finally >> not >> being implemented/deployed because of a new RR? > > Both my proposal and Casey's uses a distinctive tag in the DNS names, > so they could both work either with a new RRTYPE or using TXT records. > TXT records are way too overloaded. bad design. we shall stop using TXT records for extending the DNS. Marc. > SOPA needs a new RRTYPE. > > R's, > John From nobody Sat Mar 26 07:38:09 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D4A12D50C for ; Sat, 26 Mar 2016 07:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MzOebyy+; dkim=pass (1536-bit key) header.d=taugh.com header.b=Vit/Teht Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMst-clPuW33 for ; Sat, 26 Mar 2016 07:38:06 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DF112D1E4 for ; Sat, 26 Mar 2016 07:38:05 -0700 (PDT) Received: (qmail 52038 invoked from network); 26 Mar 2016 14:38:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cb45.56f69ecc.k1603; bh=BXNlamVaIhnJZRrCArIW0h8hkOszyfB/sbas+S+HgWM=; b=MzOebyy++qqfZ/6gqepmpQQK/IALSBFG6pAVsumftBJxHHkoIduVPHSHKh+/1UJZyoAg/RHiPq6EQqgKLN0fGr1diOb/aMTvEY5BlXjxxGGWiyKRlZIPv3QDbB3H9KB28svzzWdTQ9dciGm35+wWjyJO6TFV/GNTX8qm4haK8TRdV48Tz2qDCwkoH529ZrbY1ODpDSUFfg4NN8jUEktLl10uBpBSvKQ9d5wbac9heArWezF6oC8yv/WkK2tfuwOl DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cb45.56f69ecc.k1603; bh=BXNlamVaIhnJZRrCArIW0h8hkOszyfB/sbas+S+HgWM=; b=Vit/Teht5OCpllaegK9hT00SXNuPUtkjqc2xDJ6BpvNux1RB6Oceqa8ZoIs01gyMlyN0Rzby0KJwdIQt0WC2hZqzH4agzJM0WQ0p32gcFm+nxA6lQ7UnY3IWok8uD6w7pYAAuU/Mz3rwaD57eGsm6mmMF76tj6oEwPR9NUFiU3E/rk43xngsuoWNcDBOLa/z8OettPUfzY6hyuqglzU1obCK9UnmyEeVixp3IKUL/i5yrMOCeYsfudfX96FMHJ5s Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Mar 2016 14:38:04 -0000 Date: 26 Mar 2016 10:38:04 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-624611155-1459003084=:21819" Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 14:38:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-624611155-1459003084=:21819 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >>> best for dbound. So I’m asking the same question we had for RDAP: >>> while an in-DNS a good solution, does it have the problem of finally not >>> being implemented/deployed because of a new RR? >> >> Both my proposal and Casey's uses a distinctive tag in the DNS names, >> so they could both work either with a new RRTYPE or using TXT records. >> > TXT records are way too overloaded. bad design. we shall stop using TXT > records for extending the DNS. You can't have it both ways. For applications with distinctive tags like DKIM where the names aren't shared with other kinds of records, TXT works fine. If we adopt something like what Casey or I have proposed, we can do that. On the other hand, if we want to use new record types, we need to face the fact that deploying new types in practice is hard. (And "deploy" means a lot more than installing a new version of BIND.) This seems unlikely, since recent messages remind us that a lot of the DNS community remains in deep denial about what the real problems are. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --0-624611155-1459003084=:21819-- From nobody Sat Mar 26 11:19:31 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633CC12D563 for ; Sat, 26 Mar 2016 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOpqioQh9W9e for ; Sat, 26 Mar 2016 11:19:29 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 3825812D50B for ; Sat, 26 Mar 2016 11:19:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id ED19410AF9 for ; Sat, 26 Mar 2016 18:19:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOex65SjFbaI for ; Sat, 26 Mar 2016 18:19:28 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id 4E91810ACB for ; Sat, 26 Mar 2016 18:19:28 +0000 (UTC) Date: Sat, 26 Mar 2016 14:19:26 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160326181926.GS5239@mx2.yitter.info> References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> 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: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 18:19:30 -0000 On Sat, Mar 26, 2016 at 10:38:04AM -0400, John R Levine wrote: > > On the other hand, if we want to use new record types, we need to face the > fact that deploying new types in practice is hard. (And "deploy" means a > lot more than installing a new version of BIND.) Agreed. > This seems unlikely, since > recent messages remind us that a lot of the DNS community remains in deep > denial about what the real problems are. Where were these messages? Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Mar 26 16:15:46 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5812B12D681 for ; Sat, 26 Mar 2016 16:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95xbud-qmrnc for ; Sat, 26 Mar 2016 16:15:42 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 89A4312D680 for ; Sat, 26 Mar 2016 16:15:42 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id p65so58984834wmp.0 for ; Sat, 26 Mar 2016 16:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=IEutqdcg0bAfjRYSZdYZSOXeQf+bn6KLaYH/M0+4i1Q=; b=hjXvY8h0pZ3JJfjFv63oUDw8GEBBzTH3u6apj1kiAb3mjmlQr5XUQaiJ1wjfRU37o7 fuK6rPn9iK7HRcZ6iRQfqs/Mvi6Kl1U8N0Zb7aiwN7jWZWBQ6ZMeYdGrGRzQU5h0pGnS ZnBUTFglBHnMxolDmuX6FnTuxp9zaJGSstG1TVTyPfrQ81AHRmamktuHzN4+hgD/PHMd 0otV1kvdiFu2xGBUWntcp/p5OUje2G0lIJcEclW8r3ClL53TiT46ZvlHFBZqsPGvcErg 3Zd0BEAK4jc3EfYY0UeK8qzR/Ktu6Df4Jb8TeaHxWMcPZORU/F4gIxsSFDKy2/l+YYKS 4bXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=IEutqdcg0bAfjRYSZdYZSOXeQf+bn6KLaYH/M0+4i1Q=; b=fu40lJnbDPYaZeCuQ5WZlKc5sP8pMd/FHiFGEEko71jmfhn1HNT7TXx7k6xV8hBl3N 2ZcWrkzo2I1KF2d2pNWNSG/RSZohw0yIUseRf9eCBAJo/Oh23tEsd5vAzAwj/v/YTyF7 PuPvwK4Dgf47/+4EfINd2y8i+l1sOeihvepGSTGzQ5e1XqmvPADAim7OM1c3j8mjMNQI 4oHtovypIt7i1wW3vmTamlsmTQLBwqpuifTALRjfpt4SUyUFxAhfJW1tUS00Avv0/lrf mwwdLRw2//5td/z7jPwxXwtjlPnL5qieN+hlu4XErqR/i1euf7re4Utx4ULRGS9E0e+R r6WA== X-Gm-Message-State: AD7BkJIlUitVs1l8FHwCXfvIicRcsv8TLorJUyIxH05CIFdFqS6HNsQ9Z/bJYKR5eG/ruQ== X-Received: by 10.28.129.7 with SMTP id c7mr3324197wmd.11.1459034140921; Sat, 26 Mar 2016 16:15:40 -0700 (PDT) Received: from ?IPv6:2601:647:4300:6ed2:3e15:c2ff:fede:9b90? ([2601:647:4300:6ed2:3e15:c2ff:fede:9b90]) by smtp.gmail.com with ESMTPSA id m141sm3376683wma.3.2016.03.26.16.15.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 26 Mar 2016 16:15:39 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BFADE783-7D03-4AA1-A20C-DB6EF188C5A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: David Conrad In-Reply-To: <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> Date: Sat, 26 Mar 2016 16:15:36 -0700 Message-Id: References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.3124) Archived-At: Cc: John Levine , dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 23:15:45 -0000 --Apple-Mail=_BFADE783-7D03-4AA1-A20C-DB6EF188C5A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 26, 2016, at 6:01 AM, Marc Blanchet = wrote: > TXT records are way too overloaded. bad design. we shall stop using = TXT records for extending the DNS. Agreed that it's a bad design, but I thought the debacle with the SPF RR = and the continued assertions that it is too hard to deploy new RRs = guaranteed we'd be using TXT records in the future (at least for = anything that is expected to scale). Regards, -drc --Apple-Mail=_BFADE783-7D03-4AA1-A20C-DB6EF188C5A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW9xgYAAoJENV6ebf0/4rX7AQH/0F4W2Fj7CO+FiC9mldRHHYw rjfiz/ddVfOA16OIh0+GLj6wRwLas+/eJV4zaYm6uXIymVeImZdpdyBVeQyWWOX9 inKGYWVnH1en5Pm8X+l+NmdzRpMe4ksVJxT89domIMnawDQe//hC9yTkv2+FL50v KMzltVBPGDmPZq3nlAq2eUuY0oi3VOBQuapHyeaq5MHOhGa9HGgpOMAnuFghEqGC 5YaCSwCSvE+cShTTY5irMQeY5zS7DE3YilUg/h1I/M6Pc1jxWKzc60bov6l/A7oB gi7VhgoFc1iogHKsqoAsCKRI7rLDlOpl8NH2bpTs7ueJpGKbBFRgl9+6BbLCJ2Q= =UsbK -----END PGP SIGNATURE----- --Apple-Mail=_BFADE783-7D03-4AA1-A20C-DB6EF188C5A8-- From nobody Sat Mar 26 16:20:19 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDCA12D69D for ; Sat, 26 Mar 2016 16:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCGRF8kt-fAv for ; Sat, 26 Mar 2016 16:20:16 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 A4FDD12D68B for ; Sat, 26 Mar 2016 16:20:16 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e6so122288668vkh.2 for ; Sat, 26 Mar 2016 16:20:16 -0700 (PDT) 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; bh=K8/pqpyC3cL8NJzkhK4k7fSZ7OY2/tzq/3ro1JUFF6s=; b=oV6nbVEErfQHYcEMHLalEO2q/REQWo65+4gkzm2ksJiThBGNI/sL7rfQlEjlAVlBzZ Urjk5WMY7pnzHtgIO8X8p+wnccV0ItyQMLlK74pA7zmnSaywtyIhc0+HHzEwxqw6c+2J l8YxIpsrdCQlvLM+5/ItNOCM+p+9hxTv6O6WYSle/p7v2a9nkyuk7I9OH8SBXAhX7p4w Oi0zDysaz0COIgzsr9Vf4Bb5WqKwbIYlobyoSw8mfA0j3B6LYtuugs2E/5rDUk2tIjIm XKWpq+9EY2UztVXiBvPIn7IaTZPDiADt1uNOkttIY+6O2/q1WVN5fq30+lsSqIIRacGO k9jA== 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; bh=K8/pqpyC3cL8NJzkhK4k7fSZ7OY2/tzq/3ro1JUFF6s=; b=NLNlFc6FoskvSNkzgybVqcWgRCXNlTW5l67+o0Xfg7twYMy22ipuCYDFnJDu8dawX3 31ad4HeWsONbcFgPK6V6vmydUV6qRlSz+t1aQ/78uTQpFJkSxc7/EjRrwQuCHPDBTUhc gkWzCMYr/W6eH1+gDfExIfS8WlyBcCvbKyOGxEaqfjZgatNH2m0DWWV9mYlpYQbZ5aQW iRoS3mS6L3zRzXTnw6MfGa3oGRlYmj3d1A7p66v7wJswHPQs1m5sYFN7L9p5yl1na65c iImXveTfvvMDYonmOsn+P+m5mgbUuVf6wkZNrb6ta64PxqulilcuC+peocVOLAVN0RTc AUiw== X-Gm-Message-State: AD7BkJJlgvZmk6q4TQztqMQr3eCyKghimLsiHLTh6BOlX/vdyNt/WG12SzTaWeBK1ukjBmxJaxYm+H9zWJNP8g== MIME-Version: 1.0 X-Received: by 10.31.151.11 with SMTP id z11mr10707190vkd.131.1459034415656; Sat, 26 Mar 2016 16:20:15 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sat, 26 Mar 2016 16:20:15 -0700 (PDT) In-Reply-To: <20160326181926.GS5239@mx2.yitter.info> References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> <20160326181926.GS5239@mx2.yitter.info> Date: Sat, 26 Mar 2016 16:20:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a1140f86a0f750f052efbec82 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 23:20:18 -0000 --001a1140f86a0f750f052efbec82 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 26, 2016 at 11:19 AM, Andrew Sullivan wrote: > > This seems unlikely, since > > recent messages remind us that a lot of the DNS community remains in deep > > denial about what the real problems are. > > Where were these messages? > Starting on February 9, the RFC6686 debate happened again on the SPFBIS list. -MSK --001a1140f86a0f750f052efbec82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 26, 2016 at 11:19 AM, Andrew Sullivan <a= js@anvilwalrusden.com> wrote:
<= div class=3D"gmail_quote">
> This se= ems unlikely, since
> recent messages remind us that a lot of the DNS community remains in d= eep
> denial about what the real problems are.

Where were these messages?

Start= ing on February 9, the RFC6686 debate happened again on the SPFBIS list.
-MSK
--001a1140f86a0f750f052efbec82-- From nobody Sat Mar 26 17:34:51 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73F012D113 for ; Sat, 26 Mar 2016 17:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=hqQhcira; dkim=pass (1536-bit key) header.d=taugh.com header.b=MnSHFMHw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iWwL6SyKdip for ; Sat, 26 Mar 2016 17:34:48 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9118012D0AA for ; Sat, 26 Mar 2016 17:34:47 -0700 (PDT) Received: (qmail 96712 invoked from network); 27 Mar 2016 00:34:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=179c7.56f72aa5.k1603; bh=qhGPikukmKZB5fUQR5LCiCJVu78UjSHXrv4gKeIOURM=; b=hqQhciral7QDje+aowRjiYXwfLzl9vE++ddKFcmIgnQVwnaxs/tRfRLzNF1HtgFBiulTt6G4ilKW1+OSzQgOXH3nABmyCO+QGxzzgjwBrfFPcvVpNNGlN+og7m4GIhhXE16NA5qMcOYgGr9Fy32iyS9MR/pvz8TY7IDlgCJsnKQc9POzSsLvWIkxCSvDQTamyWArnKA4L1OFDtQbgnMoAqyBvGmKShH0p46V0xP7Ra/8bHjWF5WxFaJ6JuvvLk3E DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=179c7.56f72aa5.k1603; bh=qhGPikukmKZB5fUQR5LCiCJVu78UjSHXrv4gKeIOURM=; b=MnSHFMHwrZfBvAuf19S9gjedtXKn1qOZvdDXI7sG/qv8jAUnVXI38gbQSNTR5Av+J/5mWQiNm5Rt1x/4egF4IcjNM2EpwrWkGBe5pVNALy8POkmk+mZvjNKLR2TSxXwleE1737wMCpq8MrvjOXUCJ3zqyqCXAW+dcUcsBWxMk/EYv99ZTI/T8BvXCBK0MO7YZpv3++CmnGPsB53yEodG6SQQU6DJNTYs/SZVQWb+VGfZTZCS0s8Im/iA50nTWsi7 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 27 Mar 2016 00:34:45 -0000 Date: 26 Mar 2016 20:34:44 -0400 Message-ID: From: "John R Levine" To: "David Conrad" In-Reply-To: References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 00:34:50 -0000 >> TXT records are way too overloaded. bad design. we shall stop using TXT records for extending the DNS. > > Agreed that it's a bad design, but I thought the debacle with the SPF RR and the continued assertions that it is too hard to deploy new RRs guaranteed we'd be using TXT records in the future (at least for anything that is expected to scale). SPF was an unusual situation since there was already a lot of running code using TXT records. But the people running that code had already gone through a lot of pain to get provisioning systems to handle TXT records, and they correctly saw that there was no benefit whatsoever to them to switch their working code to yet another RRTYPE. So long as the DNS crowd remains hostile to doing anything to make it easier to deploy new RR types, yeah, it'll keep being too hard. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Mar 26 18:00:14 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6386412D0A6 for ; Sat, 26 Mar 2016 18:00:13 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4XKtKpGJuPS for ; Sat, 26 Mar 2016 18:00:11 -0700 (PDT) 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 CE6E312D095 for ; Sat, 26 Mar 2016 18:00:11 -0700 (PDT) Received: from [192.168.1.168] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u2R10AFx014607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 26 Mar 2016 18:00:11 -0700 To: David Conrad , Marc Blanchet References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56F73097.5040906@dcrocker.net> Date: Sat, 26 Mar 2016 18:00:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 26 Mar 2016 18:00:11 -0700 (PDT) Archived-At: Cc: John Levine , dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 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, 27 Mar 2016 01:00:13 -0000 On 3/26/2016 4:15 PM, David Conrad wrote: > On Mar 26, 2016, at 6:01 AM, Marc Blanchet wrote: >> >TXT records are way too overloaded. bad design. we shall stop using TXT records for extending the DNS. > Agreed that it's a bad design, but I thought the debacle with the SPF RR and the continued assertions that it is too hard to deploy new RRs guaranteed we'd be using TXT records in the future (at least for anything that is expected to scale). TXT records, under an _underscore-based naming scheme, works just fine. Deploys easily. Has no usage conflicts. SRV. DKIM. Etc. Etc. Etc... Oh, and ummmmm... https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Mar 26 18:07:54 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84C912D0AF for ; Sat, 26 Mar 2016 18:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8WAjpCX0sjS for ; Sat, 26 Mar 2016 18:05:07 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768F912D095 for ; Sat, 26 Mar 2016 18:05:07 -0700 (PDT) Received: from [10.32.60.36] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2R150uD079411 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2016 18:05:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.36] From: "Paul Hoffman" To: dcrocker@bbiw.net Date: Sat, 26 Mar 2016 18:05:00 -0700 Message-ID: <1A6F8665-E849-4471-84BC-32D238B0A69C@vpnc.org> In-Reply-To: <56F73097.5040906@dcrocker.net> References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> <56F73097.5040906@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Sat, 26 Mar 2016 18:07:53 -0700 Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 01:05:08 -0000 On 26 Mar 2016, at 18:00, Dave Crocker wrote: > TXT records, under an _underscore-based naming scheme, works just > fine. ...but only if there is no zone cut where you want to put them. As Andrew pointed out upstream, some of the use cases for DBOUND require that an owner be able to say "at this node, ...", not "at the node above me, ..." because the responsible party can't put records at the node below them. > Deploys easily. Has no usage conflicts. > > SRV. DKIM. Etc. Etc. Etc... Fully agree on that. I'm in the pro-TXT fold as much as I'm in the new-RRtype-if-you-need-it fold. --Paul Hoffman From nobody Sat Mar 26 19:21:18 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62C12D0A4 for ; Sat, 26 Mar 2016 19:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QZAfAkym9kG for ; Sat, 26 Mar 2016 19:21:16 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BC3128874 for ; Sat, 26 Mar 2016 19:21:15 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l68so49895806wml.0 for ; Sat, 26 Mar 2016 19:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=VubCz8R/0LC42ncXbaVbkfdviUjjWsvVl54HVAhWokw=; b=AolQs5RzlvhuXggIcd7AGlwGe68Mh6mYej4x0fmLUiAQtnBYmrArcneEHSV8ERXYWm N6zN2D+WP+OlIVYzvrKw+nW088F08WAlzvL7okOcfUVYWWfmC+mHigxp3fdYSFrmVXKx cG8QJw9aSv7NuIMKukaVlkMFV/HkqUQ7u6zRjhGn3ESXyyDPgwj3oCaPGKlZYfdpAmgQ PwmODndODqdoIPtd+oc0o/kjGem8RFN4FxzU0plW2+aGHJzI6XZZ4Hk0aIhRJuBe8OKG Ert4PqiiaajiDDnSJEJEP558B68WHGF6Jh64tihPpg+PrVvuFiRXU+ohs+9G5ou7MF7T hYzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=VubCz8R/0LC42ncXbaVbkfdviUjjWsvVl54HVAhWokw=; b=TfAaaOkJmRVnh4jaLaYQhekPfuXvGJy3jzdMLyh4QmY/w54LqW+7+JVlqYvvO+qe7v dt37qOdSQyDxU9wKZjZE42nnhrwzA75Vadk0PlC/EJY2ALlXJ0lxgXByPXDlAofLjSjr 8uXIvB3idFyD47GYyoSe01JJsJqBoFffN/lP3rSWpbHyhoiCO1vMm7Up2Ysu60IkJMvE IgDt2ONHy0GEuaJg1nil7cvLMrwBn3e1IkEI9XGSDuX/4vYbLgh9WwbKBO0fmUajYOCA vvm4ran8O6fGmMzMofwaWsWzcNsbtJiVsMhtTz1dHcR38ucp+q4juoEyxsKrHK9W8veg wFgg== X-Gm-Message-State: AD7BkJK5AO5a2OIEVKsZKIpYwt66+eT0uHtGZcxhRQcKMpXu5vVMegP8nm5glQiyLaQdLQ== X-Received: by 10.28.19.204 with SMTP id 195mr4181059wmt.1.1459045274172; Sat, 26 Mar 2016 19:21:14 -0700 (PDT) Received: from ?IPv6:2601:647:4300:6ed2:b9bf:51cc:bdba:df50? ([2601:647:4300:6ed2:b9bf:51cc:bdba:df50]) by smtp.gmail.com with ESMTPSA id g9sm3776370wmf.15.2016.03.26.19.21.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 26 Mar 2016 19:21:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2BD8E555-CE67-4760-ABA0-03099127E0E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: David Conrad In-Reply-To: Date: Sat, 26 Mar 2016 19:21:08 -0700 Message-Id: References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> To: John R Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 02:21:17 -0000 --Apple-Mail=_2BD8E555-CE67-4760-ABA0-03099127E0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, On Mar 26, 2016, at 5:34 PM, John R Levine wrote: >>> TXT records are way too overloaded. bad design. we shall stop using = TXT records for extending the DNS. >>=20 >> Agreed that it's a bad design, but I thought the debacle with the SPF = RR and the continued assertions that it is too hard to deploy new RRs = guaranteed we'd be using TXT records in the future (at least for = anything that is expected to scale). >=20 > SPF was an unusual situation since there was already a lot of running = code using TXT records. But the people running that code had already = gone through a lot of pain to get provisioning systems to handle TXT = records, and they correctly saw that there was no benefit whatsoever to = them to switch their working code to yet another RRTYPE. I suspect all of these arguments will be reused. > So long as the DNS crowd remains hostile to doing anything to make it = easier to deploy new RR types, yeah, it'll keep being too hard. I'm unaware of hostility. I am aware of interests, particularly in the = (generally non-DNS) folks who write the web GUI front ends to DNS = provisioning systems, to not write any more code than they have to. But = perhaps you know different people than I. Regards, -drc --Apple-Mail=_2BD8E555-CE67-4760-ABA0-03099127E0E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW90OUAAoJENV6ebf0/4rXSJ4IAJ1B9ZBuC3RGG9mc94cyrvzJ MTHzOS6FLJK6rSvrm5Jh3/NEx6mJ48Ea6a71+7fSLoSDIodepmxrdArVDbuvHOpz QDUw1+/mW5mJQXO2TdnopnDu5hHauMDJOieFaAdXy36DykmQtKnfy0I1wWU0awgt dxoYHtno6Nmu9WaKZ+Kyg0G76CO+Fax+Jt/Yxx30Hwp7buQgop0LQSmZe0qLi5Zz Kw1p17kxInQPUel0WvLjGd6wRURKHBeykEwd3xCXywaEgcXme1Yco83wgUR72tkw vUp28OEcRDFn0hUrpy91AxMNzpNnus4LAGpdfs9z7BDsRMmYUgbH2dG6bSjT/Rw= =9ANj -----END PGP SIGNATURE----- --Apple-Mail=_2BD8E555-CE67-4760-ABA0-03099127E0E1-- From nobody Sat Mar 26 20:37:59 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72A12D0AF for ; Sat, 26 Mar 2016 20:37:57 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNJdTaHRTjRy for ; Sat, 26 Mar 2016 20:37:56 -0700 (PDT) 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 32F5F12D0AE for ; Sat, 26 Mar 2016 20:37:56 -0700 (PDT) Received: from [192.168.1.168] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u2R3btaZ019468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 26 Mar 2016 20:37:55 -0700 To: Paul Hoffman References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> <56F73097.5040906@dcrocker.net> <1A6F8665-E849-4471-84BC-32D238B0A69C@vpnc.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56F75590.4030100@dcrocker.net> Date: Sat, 26 Mar 2016 20:37:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1A6F8665-E849-4471-84BC-32D238B0A69C@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 26 Mar 2016 20:37:55 -0700 (PDT) Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 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, 27 Mar 2016 03:37:57 -0000 On 3/26/2016 6:05 PM, Paul Hoffman wrote: > ...but only if there is no zone cut where you want to put them. As > Andrew pointed out upstream, some of the use cases for DBOUND require > that an owner be able to say "at this node, ...", not "at the node above > me, ..." because the responsible party can't put records at the node > below them. The semantic of an underscore branch to domain foo is that it provides attributes associated with foo. The "above me" is built into the construct, so that the semantic of data in the underscore branch is not "above me" but rather is "here are some attributes associated with foo. I understand the administrative issues that you cite. However the operational difficulties in creating name entries in the DNS are generally significantly less in effort and time than in getting a new RR to be useful, end-to-end... By some orders of magnitude. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Mar 26 21:07:12 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB02B12D0F2 for ; Sat, 26 Mar 2016 21:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=PvIuNyCh; dkim=pass (1536-bit key) header.d=taugh.com header.b=OfHw7w6l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw3zFjquK8pE for ; Sat, 26 Mar 2016 21:07:09 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2885512D0C9 for ; Sat, 26 Mar 2016 21:07:09 -0700 (PDT) Received: (qmail 16251 invoked from network); 27 Mar 2016 04:07:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3f7a.56f75c6b.k1603; bh=773SbG4M9K+NMNz61eod51h8HObBhzsX8KD2Wcorj0I=; b=PvIuNyChpaYtzycJDewfMJOmbiEGWdaYz+iKww8QKYt+k+yQ3Gimuh1sbBG0YI1i5iJeN/QRgl1L4uM21EMGiT4/pC07pXIv+vW3DmrJUXd0jgGGoVSfILAQ3MY2R5JLLoVuBjqFXzMRn0Hzw5ynAhQg91Z6ctThkwUUaL2+BDNqzGTxOh4RxAuIBO0WLhzGF2XRSws1b7eMpLEXNAjCsh7TDjOVwsohftBrkHPL9/HYIMWh7kaDEh54P8bw0EcS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3f7a.56f75c6b.k1603; bh=773SbG4M9K+NMNz61eod51h8HObBhzsX8KD2Wcorj0I=; b=OfHw7w6lWiIDVvV9xByKf/Yd3C3Gr3dyVKjbwQySDNqPLZwdRG41DEV8DY7ikiaGD/Kb8Jh6Y5LhRz2+FexvsjXmwVTOrPVXpBF5neLdPKhmXpaoAKFcAWclryQ/eGMj5vH0XOzCiXPNoAwoNxfwUpmfAcYEN1/K95h+gkGUhKKE5bQ+Gkf185DU+tiA19mBwMRcMV06WPRQJX6F5RaFK47SN6JTUh98WLsG67ptfXYEmjjJ62YSTfvUy8YxQ3w9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 27 Mar 2016 04:07:07 -0000 Date: 27 Mar 2016 00:07:06 -0400 Message-ID: From: "John R Levine" To: "David Conrad" In-Reply-To: References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 04:07:10 -0000 > I'm unaware of hostility. I am aware of interests, particularly in the > (generally non-DNS) folks who write the web GUI front ends to DNS > provisioning systems, to not write any more code than they have to. But > perhaps you know different people than I. We GUI front end writers would like something like my dnsextlang proposal so the front ends could automatically configure themselves to handle new RRs. It has been kicking around for at least five years, no WG has picked it up yet. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 27 09:20:01 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E041912D1B1 for ; Sun, 27 Mar 2016 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNEjcv75lhyV for ; Sun, 27 Mar 2016 09:19:54 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 5907C12D1AD for ; Sun, 27 Mar 2016 09:19:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id A725F10AFA for ; Sun, 27 Mar 2016 16:19:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR8cNXfJoHnc for ; Sun, 27 Mar 2016 16:19:53 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:87d9:1182:60a0:df67:d01d]) by mx2.yitter.info (Postfix) with ESMTPSA id EBAEE10ACB for ; Sun, 27 Mar 2016 16:19:52 +0000 (UTC) Date: Sun, 27 Mar 2016 12:19:51 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160327161951.GA16227@mx2.yitter.info> References: <20160326025652.14512.qmail@ary.lan> <2F22DF36-B8A9-4CE8-86F2-8592CC8283AB@viagenie.ca> <56F73097.5040906@dcrocker.net> <1A6F8665-E849-4471-84BC-32D238B0A69C@vpnc.org> <56F75590.4030100@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F75590.4030100@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 16:20:00 -0000 On Sat, Mar 26, 2016 at 08:37:52PM -0700, Dave Crocker wrote: > The semantic of an underscore branch to domain foo is that it provides > attributes associated with foo. But I, at least, was trying to design something that could apply to any name. There's a recursive problem with underscore labels for this use, because by defition they can't work for every case (at the very least, they can't work once the name you're trying to talk about is already 253 octets long) > I understand the administrative issues that you cite. However the > operational difficulties in creating name entries in the DNS are generally > significantly less in effort and time than in getting a new RR to be useful, > end-to-end... I'm aware of the difficulties. See upthread where I talk about the deployment incentives and where the pain happens. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 28 02:11:04 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE512D73C for ; Mon, 28 Mar 2016 02:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RkRuywOjKRE for ; Mon, 28 Mar 2016 02:11:00 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F7212D11D for ; Mon, 28 Mar 2016 02:10:59 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 20so10434088wmh.1 for ; Mon, 28 Mar 2016 02:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=bvw88OOtGplAFtDmK4Py8H/eF0wkJkVdtzRIn2Vrulo=; b=njDBYkr2SzTS8saHoKMSCyNXa2wkb91a7cRdHzWnTnO87q+mxM3IEWPiB6rf09Cdfb TNLeHkMBRumgcQObiUE46hgPQC6WbQfY7C4DbEXvsKKTXBBBXbLaQiJwSIYdn24GNTg2 DzVTLfSZThpKjXIbpEd42G44d5N/ZMA2QoKPq19+Wlebc3XIWTojryY3cc7/xc7JLQup 4oxEUe1yR5vb1deisWgUUBgyBZ4P+jwwiybqkzIQT3myEEn51EevnNIOyj640ttDvBY9 2DGBrGtKnn9he0LNg5LlNuzpcPx6lidzaeQKc5QqG2m3molg+zISuw712FQ7vykgFeP6 Vbjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bvw88OOtGplAFtDmK4Py8H/eF0wkJkVdtzRIn2Vrulo=; b=KnQfo5cLWIMvRle31cpl+YS0g2LiGXdjS0TQODdoIg6/3ttAgYZ4PMZ4hUYrbC6ZH4 M/gd/oQSuq5dWVG9klB/783c9jKxoBiPMQtd4zIG5AKtzPDRRanN6Ct8+9gryfFNkKDU k/FH7y8+Z6l3raSwH6xAfxqst5a9EP7YZGu7toETYUqSpXWtdrb0FPsMq+7QDZISeZ+w MiW3T2zEs0dv2k+ib9x7hjr9r2N+fwvpyHmbXcger/xfOmdwdr6TobsSOUMCPraYS7US Al7sQ1jl8NHErEp6A7tmSGKskTjMc559KDzKPOfE+VkqCW+lzAjwrlMuAzIXEYF3ZPLG VBJw== X-Gm-Message-State: AD7BkJKubnbeqN/9SihzjsybPjYeBKifWT/aQnZGRz3S70XR3YfT9qJPuJ/BpoBdEHfRdw7+ X-Received: by 10.28.11.69 with SMTP id 66mr9907783wml.103.1459156258064; Mon, 28 Mar 2016 02:10:58 -0700 (PDT) Received: from [192.168.43.209] ([31.76.78.168]) by smtp.gmail.com with ESMTPSA id i5sm23781336wja.23.2016.03.28.02.10.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 02:10:56 -0700 (PDT) To: Paul Hoffman , "dbound@ietf.org" References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> From: Gervase Markham Message-ID: <56F8F033.40209@mozilla.org> Date: Mon, 28 Mar 2016 09:49:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 09:11:03 -0000 On 24/03/16 00:24, Paul Hoffman wrote: > - If the WG closes without standardizing on one of the proposed new > solutions, the highest risk is that the volunteers running the current > solution stop. That's a fairly small risk; as the data is open, someone else could just start. In this unlikely event, there would perhaps be a risk of fragmentation (multiple competing sources of truth). However, as PSL maintainer, if we were to reach a stage where I and Mozilla were no longer interested in or available to maintain it, I would try and make sure it was handed over well. Gerv From nobody Mon Mar 28 06:26:40 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FADB12D93E for ; Mon, 28 Mar 2016 06:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5w3qm7wFGXw for ; Mon, 28 Mar 2016 06:26:28 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D9312D932 for ; Mon, 28 Mar 2016 06:26:27 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id k1so154286070vkb.0 for ; Mon, 28 Mar 2016 06:26:27 -0700 (PDT) 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; bh=2VIO0s/Uw57ziQyXM3bW+afnlzSNUQi9VwjJdiWyGXo=; b=MchcGYHQAkivg7ufBVrLegVp0kY5pR/F+pm2UL9kQJqwoPp9nfCVE9BAZPumRMwzZa lVK4njEjXLOJxtPtLqtZxNnrTRqn5xvlvVy5n9S/4T4mQ+msodg9UsB8f2d/e7PAjI81 sa5++j2i8d3qfZ8gDs4n6w4v/qb1MtCRJ24Uq4Qr9ufjg4cZ0+LXwH24Ks3TWhP8N4xN GE7HJnCUjaasL7vS5hJRZm22ZdxQFqvYUVAZ1IezGoa+xio5PNNYMsP4LW4X2AENmeUk kjD545hWuiqW93I2Cp1fZkMFKu901qzkyT/LzAO4M6eS037zi3+VPZ8cdru2TggsjGWl hQNg== 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; bh=2VIO0s/Uw57ziQyXM3bW+afnlzSNUQi9VwjJdiWyGXo=; b=gpECznIhQ3uo2mSK+8KLJOTCFToSA4KilPrERv0kH8GVQYCc/GeTzrh133n0QvIjjP h//YXhc6gJO1bn/T+/M3ybL2QAyFNE/5jPNDVnK0pLsCF6j2CLgms6MRLvt77zM/pnUp O99os5HleEkfMS9PWbOYziy7ew80Fyj0GiVzY8gJRrqV36piJL6FR73ftcqgaIUwTU07 vi2zqbmqjaoDsWN1uJkRXpQcEF5rurca1913JOl0OAqsmrb5LkB066zd3s6QtE/yXA3f l6r+8cbrUEjVROx2aYOBQz8efgcwk1Awg3dlwWqbsDpAG5E0TeQ6XNnI7WXb4dOQUYGk kp0w== X-Gm-Message-State: AD7BkJLV1EekuplXnqCWxofs5e01qJQbvSdUDOEk4ILNCzgk8z6d/Bm1qUATEfpelUeiJI8s08lgqVfHUO8WOA== MIME-Version: 1.0 X-Received: by 10.159.36.172 with SMTP id 41mr3060823uar.123.1459171585274; Mon, 28 Mar 2016 06:26:25 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Mon, 28 Mar 2016 06:26:25 -0700 (PDT) In-Reply-To: <56F8F033.40209@mozilla.org> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> Date: Mon, 28 Mar 2016 06:26:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Gervase Markham Content-Type: multipart/alternative; boundary=001a113e40ae01b7d0052f1bdcb4 Archived-At: Cc: Paul Hoffman , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:26:31 -0000 --001a113e40ae01b7d0052f1bdcb4 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 1:49 AM, Gervase Markham wrote: > On 24/03/16 00:24, Paul Hoffman wrote: > > - If the WG closes without standardizing on one of the proposed new > > solutions, the highest risk is that the volunteers running the current > > solution stop. > > That's a fairly small risk; as the data is open, someone else could just > start. In this unlikely event, there would perhaps be a risk of > fragmentation (multiple competing sources of truth). > I think there's a risk of fragmentation already. Someone who doesn't like a choice you make about an entry that gets added (or omitted) could start doing their own now. There certainly are a lot of DNSBLs around, for example. Then people would have to decide which PSL they want use, or how to aggregate the results after consulting both. -MSK --001a113e40ae01b7d0052f1bdcb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 28, 2016 at 1:49 AM, Gervase Markham <gerv@moz= illa.org> wrote:
On 24/03/16 00= :24, Paul Hoffman wrote:
> - If the WG closes without standardizing on one of the proposed new > solutions, the highest risk is that the volunteers running the current=
> solution stop.

That's a fairly small risk; as the data is open, someone else co= uld just
start. In this unlikely event, there would perhaps be a risk of
fragmentation (multiple competing sources of truth).
<= br>
I think there's a risk of fragmentation already.=C2=A0 So= meone who doesn't like a choice you make about an entry that gets added= (or omitted) could start doing their own now.=C2=A0 There certainly are a = lot of DNSBLs around, for example.=C2=A0 Then people would have to decide w= hich PSL they want use, or how to aggregate the results after consulting bo= th.

-MSK
--001a113e40ae01b7d0052f1bdcb4-- From nobody Mon Mar 28 10:48:08 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353D112DC32 for ; Mon, 28 Mar 2016 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0EWkdUcfXau for ; Mon, 28 Mar 2016 10:48:05 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBB12DC26 for ; Mon, 28 Mar 2016 10:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 21C0B10B02 for ; Mon, 28 Mar 2016 17:47:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLAFQbuDoWNt for ; Mon, 28 Mar 2016 17:47:29 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:87d9:f41a:f921:795:204f]) by mx2.yitter.info (Postfix) with ESMTPSA id 64D5E10ACE for ; Mon, 28 Mar 2016 17:47:29 +0000 (UTC) Date: Mon, 28 Mar 2016 13:47:28 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160328174727.GJ16227@mx2.yitter.info> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> 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: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 17:48:07 -0000 On Mon, Mar 28, 2016 at 06:26:25AM -0700, Murray S. Kucherawy wrote: > I think there's a risk of fragmentation already. At either an APPSAWG meeting or the BoF that got us started, Phill Hallam-Baker asserted that Comodo was already using its own private version with different properties. So in some realms, we have claims of fragmentation today. As a practical matter, we'll continue ot have that, since people will make their own decisions about what they are willing to believe or accept. But I claim that it is better to start with data from the authoritative operator of a given name than from anywhere else. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 28 13:02:58 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7C12D9F7 for ; Mon, 28 Mar 2016 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw_E5Stb0ZNZ for ; Mon, 28 Mar 2016 07:14:35 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1FC12D9BD for ; Mon, 28 Mar 2016 07:13:20 -0700 (PDT) Received: from [10.32.60.88] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2SEDJPJ092393 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Mar 2016 07:13:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.88] From: "Paul Hoffman" To: "dbound@ietf.org" Date: Mon, 28 Mar 2016 07:13:19 -0700 Message-ID: In-Reply-To: References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 13:02:56 -0700 Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:14:41 -0000 First off, I wasn't suggesting that the volunteers running the current solution stop" was much of a risk: it was just the biggest risk I could see for the the WG closing without standardizing on one of the proposed new solutions. Mozilla has a good reason to keep doing the work. On 28 Mar 2016, at 6:26, Murray S. Kucherawy wrote: > On Mon, Mar 28, 2016 at 1:49 AM, Gervase Markham > wrote: > >> On 24/03/16 00:24, Paul Hoffman wrote: >>> - If the WG closes without standardizing on one of the proposed new >>> solutions, the highest risk is that the volunteers running the >>> current >>> solution stop. >> >> That's a fairly small risk; as the data is open, someone else could >> just >> start. In this unlikely event, there would perhaps be a risk of >> fragmentation (multiple competing sources of truth). >> > > I think there's a risk of fragmentation already. Someone who doesn't > like > a choice you make about an entry that gets added (or omitted) could > start > doing their own now. There certainly are a lot of DNSBLs around, for > example. Then people would have to decide which PSL they want use, or > how > to aggregate the results after consulting both. Murray's point is a good one, but that's not necessarily much of a negative risk. If the "main" PSL continues to be updated, anyone choosing a fork of the PSL has to have a good reason to do so. I can think of some good reasons that might come up, but as we all know, the chance that even a well-maintained fork could overtake the main one in under a decade are slim. Having said that: if this WG adopts one *or even multiple* of the proposals as Experimental RFCs. and even if just a handful of zone maintainers adopt some of them, Mozilla could use those as input to its own PSL. If Mozilla chooses not to do that, forking the PSL at https://github.com/publicsuffix/list and using the scraped data would be a very low-effort work, and if people coalesced around one fork, Mozilla might say "hey, that's a good idea" or a contingent of users would just use the fork. This might be a good enough reason for DBOUND to move forward with a different charter. Instead of picking one solution for Standards Track with the too-little energy that we seem to have, we could: - Informally help the authors to get the four drafts down to two or three - Get some more review so that the authors can put more "why this proposal might not work for you" sections in their documents - Send them all to the IETF as Experimental at the same time I know that some people find this kind or resolution to IETF efforts to be a failure. Because these could be input to the PSL, or to a popular fork of the PSL if needed, I think this is actually worth our time and a bit more effort. If others like this idea, I'm willing to work on charter text. If others thing I'm crazy, I'm willing to sit here quietly. --Paul Hoffman From simone@carletti.name Mon Mar 28 07:24:52 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D0912D9A6 for ; Mon, 28 Mar 2016 07:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=carletti-name.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leWU0neggn2d for ; Mon, 28 Mar 2016 07:24:51 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0DC12D95D for ; Mon, 28 Mar 2016 07:23:29 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 191so16917965wmq.0 for ; Mon, 28 Mar 2016 07:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carletti-name.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yd4Lt+PQfhNFny+5EzNC8Me83+Si53fb75gLMh0ofKQ=; b=u3W3oPOHhxd56+y0pV+UGjRshfJGY8kDweJNt1b0ogQDAgp/NjGPGMpjA+EoiQzpvZ 6Kp8jfTLPX+Bd+RRXYssb8nIWN/mKv/3yCbimctU+28lVuA8In9bCuguF3dyKSvvWS8x ZQhoLWrFxRikCaUZErQm2QWboYenlGJtn4gVig+s7SyvayWK6UMHeMOy3ilRjB9Fp+ty dD0Md9mokg+ICKSLC7Jvx9TNptw16Sdg59J8303KoBr2aqw7UGhRXuBNAl8D7Tk1bhg0 UC7GQIb+5kLy2jgoZ1lNrM6WFKYcM0gezzaQVemh/huzLIVXVFN2EywPPItyPD3rOT+h PKgA== 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; bh=yd4Lt+PQfhNFny+5EzNC8Me83+Si53fb75gLMh0ofKQ=; b=AIXjz58sLvPFAEA0ACL718JrOGXoaGnEE2itQsQC9ZTXL5o1VWzVd7DFfyJ+qZ3bzX gsehtwAaMl2vWMKKRHAyxQTdxTaX9p3QH+QQE9VG4kj0m9Nld74u9A/EQ24b3ddCnuSQ aURPsMlfa73wm4zimnC7e3kgaH0Bl9Zj9XIBquM+SPw5lHTAbUNMfDjAtcgoQrmbr14d IEfJIwHXmCRe0FQpDoXHIiOd7nyT7qjT7gDMIL2DeHuoHIer7hJwgNQU4280cUTj2GQE uIoD6f6de8fTI4zX3XNcbR36amnRQx6Pl2RU4BUzc9WtHTR6vgn2UXDJ7jJ07NjBvZom er5A== X-Gm-Message-State: AD7BkJIj/xoMn1xb8FnFfNgxZG9gB4uVNSlcv2M2ed4Dx0YUmFl/nNdKu4A0MtJV8r44Hg== X-Received: by 10.28.103.3 with SMTP id b3mr10437659wmc.65.1459175007694; Mon, 28 Mar 2016 07:23:27 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com. [74.125.82.51]) by smtp.gmail.com with ESMTPSA id s66sm10439090wmb.6.2016.03.28.07.23.27 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 07:23:27 -0700 (PDT) Received: by mail-wm0-f51.google.com with SMTP id p65so100897917wmp.1 for ; Mon, 28 Mar 2016 07:23:27 -0700 (PDT) X-Received: by 10.28.156.196 with SMTP id f187mr11345956wme.23.1459174980981; Mon, 28 Mar 2016 07:23:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.20.135 with HTTP; Mon, 28 Mar 2016 07:22:21 -0700 (PDT) In-Reply-To: References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> From: Simone Carletti Date: Mon, 28 Mar 2016 16:22:21 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a114b3132681af8052f1ca682 Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 13:02:56 -0700 Cc: Gervase Markham , Paul Hoffman , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:30:58 -0000 --001a114b3132681af8052f1ca682 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 3:26 PM, Murray S. Kucherawy wrote: > I think there's a risk of fragmentation already. Someone who doesn't like > a choice you make about an entry that gets added (or omitted) could start > doing their own now. There certainly are a lot of DNSBLs around, for > example. Then people would have to decide which PSL they want use, or how > to aggregate the results after consulting both. While this risk exists in theory, in practice the probability that this will happen is low. The risk is generally more relevant in softwares, but the PSL is a definition list. As long as there is consensus among the major consumers and cooperation with the suffix owners (and this also largely depends on the maintainers), the master list will continue to be relevant and the primary point of interest. Forks exist, but they generally solve specific needs of single individuals. There is honestly very little interest and gain you can get by using someone else fork. Conceptually, it's like the HSTS project. I can grab the list and add my entries, but it will be totally useless as Chrome/Mozilla/Safari will continue to use that list, hence mine will have no effect. And because my fork is mostly irrelevant for anybody else, any other publisher will likely use the original HSTS list instead of mine. So I eventually will submit my changes to the primary list. Best, -- Simone Disclaimer: I'm a contributor to the PSL. -- Simone Carletti Passionate programmer and dive instructor https://simonecarletti.com/ --001a114b3132681af8052f1ca682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 28, 2016 at 3:26 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
I think there's a risk of f= ragmentation already.=C2=A0 Someone who doesn't like a choice you make = about an entry that gets added (or omitted) could start doing their own now= .=C2=A0 There certainly are a lot of DNSBLs around, for example.=C2=A0 Then= people would have to decide which PSL they want use, or how to aggregate t= he results after consulting both.

While this risk exists in theory, = in practice=C2=A0the probability that this will happen is low. The risk is = generally more relevant in softwares, but the PSL is a definition list. As = long as there is consensus among the major consumers and cooperation with t= he suffix owners=C2=A0(and this also largely depends on the maintainers), t= he master list will continue to be relevant and the primary point of intere= st.

Forks exist, but they generally solve specific needs of single individu= als. There is honestly very little interest and gain you can get by using s= omeone else fork.

Conceptually, it's like the HSTS project. I can grab the li= st and add my entries, but it will be totally useless as Chrome/Mozilla/Saf= ari will continue to use that list, hence mine will have no effect. And bec= ause my fork is mostly irrelevant for anybody else, any other publisher wil= l likely use the original HSTS list instead of mine. So I eventually will s= ubmit my changes to the primary list.

<= /div>
Best,
-- Si= mone

D= isclaimer: I'm a contributor to the PSL.

--
Simone Carletti
Passionate= programmer and dive instructor

--001a114b3132681af8052f1ca682-- From nobody Mon Mar 28 18:53:41 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8F12D0B3 for ; Mon, 28 Mar 2016 18:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRHEq9b4069Y for ; Mon, 28 Mar 2016 18:53:38 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0122.outbound.protection.outlook.com [104.47.124.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE6B12D507 for ; Mon, 28 Mar 2016 18:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KyYlqOa9vLPTpCG96zMhmVMuVLOpyrtwLDq45oe8dww=; b=n7V/9n+/Ef72Ohcs/gez+Q6YI0Dxb2ByTKK8PfY1vw1dFoZBXcsyXwc6/pI+tEnQ15CYJQu5vCKMl3B6umFv1YocExl+4xG1Z1q1hOFdrrX+fvakVdn/lL7bdRNNaAdwwCPy9LeGxIOX2iUWwcXnMmnBUnpqBzZi0CjYN4qhK0c= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0921.jpnprd01.prod.outlook.com (10.167.156.151) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 29 Mar 2016 01:53:34 +0000 To: Paul Hoffman , "dbound@ietf.org" References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F9E01D.4050007@it.aoyama.ac.jp> Date: Tue, 29 Mar 2016 10:53:33 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0002.jpnprd01.prod.outlook.com (10.161.225.140) To TY1PR01MB0921.jpnprd01.prod.outlook.com (10.167.156.151) X-MS-Office365-Filtering-Correlation-Id: 8494e080-8416-4f70-a565-08d35774f00f X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 2:XwTSrtKBNDAysWdySFGeqiA+DBNRitLdIboLVEr/qftyqSomGhh4YAsMfl00M+RXSlLSSyYWmMneSKL9zbeY8LY3GzJGn8RwMkpO6G8pv7KEtfoST5dMts6CH1TQyGSOtqRo4+R1HEHCQoOSduNaJjK1xoGSDVm8+6w1X48+mLSEX5KWR71cdy1Wvkr61Zs1; 3:rjyR+UG2ucnsZBF7D+DlmUKMoWhwIkAEFmO/VW7e3LJSt9ElJRGf9nR73mC5QimLI62v/l2fLqv4W/bNThsgi3AhyD7mCilDMYsVLoGfPmJ2Sl1Jne7oA8FfFqcHlOeE; 25:WCYM+TUHCjlKjJR9OLTzYqsTPWkIugpdPXsOmt4UYdU4HzCk0/5btWS0V5GVI7gDpx+uV17hE7yWSFFuJ0wYn07mygC2vjOPDObNnm/KhCO2rhpuXRuRnOIV+/FbLCeFB4ohaaD+Hvaz155zorFuJiw8RgG49RnlRsQNV5WNF/RNOG3BF+T17NYjI2CWq7wH+4gU8ta/BT5TFl3PZJ7YlLOrT1tiSyGvecAbbbS14e4W1l9Y7vF6E8OmaZC5iCERpN/WbdGxdv/qlQN8n+ZFzRtlSY3tyGzuOmzd6FEFjwjkWryfXRlv9TbHX5vUmFWwZA4U9Hmi1uyrkd+j+R82nyzuTJ+0ZkKYoJwxaFjCHLi6pfJWazmP1j/mVjr42NU5KTO58C43EaJG4TlDnT9RoZRgilIrHO4uFfd7WE43lDfWxU99fCeHI1EXnA8lBAmmjfqrZb27ZehERU9oZseN1KDKf0m3XVl38OwJiRb3E0E5pAtWFjN5Qm7IaPhJNeWFQybiuvqbckMZ3ek8Yg0MadwyMiybEzIpLrd6f1GLocs= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0921; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046)(6042046); SRVR:TY1PR01MB0921; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0921; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 4:1ITRA5D0jYVmvpGj2ynOth3/o5jlgXrpipXP5danfmr4pEhk8q5UERvfKeYUqINlXPkHBN5NTV9/X2lf7RuApNz8M0Vg0Q+6XRk5Wq8JbKx3xDtp7P/Z38+j6KBn2RTFIW/hK/gfbYnUQ4G7LesOstw47NSufxphdKMaYVopkKVAQ31xfjQ+yw6fkcXVaNvs6CH6rjnD9S8AFY4v+3uAPaqpvzdAcwEymxHTHz9Smt+VyUzokuwSddUcu0yB2xVXL8OvYcFKtyRNz0nQgBM2mY6/0izEoCTB7DAWd3hWITv+Q0CN7eCGxdUNsJLiUqZztVMOXleCNRVzTmqsgebkK21851EQsbajSvOTFmUT1mqu98LoOswcurDgOYlW6I68bUl3Op0A9QpSeNZkR1tFVnPM93YVwmnB6mFVXPGNqFWPjhZOUgYh6sm2rEzR/2Kh X-Forefront-PRVS: 0896BFCE6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(189998001)(3846002)(23676002)(586003)(83506001)(77096005)(47776003)(86362001)(5004730100002)(2906002)(59896002)(230700001)(2501003)(93886004)(65806001)(5008740100001)(107886002)(64126003)(92566002)(50466002)(2950100001)(66066001)(65956001)(50986999)(42186005)(87266999)(54356999)(65816999)(76176999)(33656002)(5001770100001)(81166005)(1096002)(74482002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0921; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwOTIxOzIzOm5yR0NGSzZsNFRRM3FaUWszN294UDFNNXNX?= =?utf-8?B?U2puaVBZQjNGc3pEcGJoWVBvblhHWmtIY1lMSkZ2TTBiS1JycTRTY1E3RWN5?= =?utf-8?B?Q3VJM0R2ZXhrbE42R0M4ZGRZM29tbnNia0c0ODNEdEp3N2t3eEYzaFV0aDBW?= =?utf-8?B?NC9wVGVLS0t0M1c3THMrSDB6ZjNXc1hrYlN5OUJ5bzFXMjBVV2MyV2pyYkNp?= =?utf-8?B?bEM1ZW1GcHdsOXNpUHJaWHBVWjJvMkZLeHBZckErWWZLOUl1RWNVdStULzNs?= =?utf-8?B?Y09RRzZwK3p0eEtXVkcybk1hZmxaekJSSHozc1NHd0lManJqeldpeHozZzBm?= =?utf-8?B?dnVQc2hRU25aZUorMEhraXdlaVVDd1VNajR3bmRERWZucFNobGJmdU1nbEtV?= =?utf-8?B?TzBWUG5pb0JTTlRUMFFKVlYwajI2WTJhN2JoQ0d2MDFiZ1Avdng5K1FVWkx0?= =?utf-8?B?R2lPM20zR3BFb3Bpem9DVGFSYXhlOHhKZndRNHN1eDAxTVN4N2pVeGg5aGZ2?= =?utf-8?B?VTIya1RxeTFoKzZ1MjduN1B1THVaQkhJZEx5Q2NPNURLR045RFZhc1l2bW42?= =?utf-8?B?NWxxbHBNcmhFU0pQRHJvQkoxNlFiNy9VNExXeGFLTTZ6L0dBSzBZZnNzMHFH?= =?utf-8?B?ajE5MURTd2FkSTQweFNUamIvZ3hFWDAzZytacVR3VXUyL3FybkNreStJOVcw?= =?utf-8?B?ajFtdkRxYVQ3OWlZbVlUZGxwNWhld1o3MWhJUnFLcVhHeXl4a0RCV1B6ZXE1?= =?utf-8?B?dHdJZjF0d0tTU2xsNllneFRucVFkNlBrdy9BSlZMN25MV1JYbFVwUzZYb2Zk?= =?utf-8?B?bllMekpodW1XNmlOdnNUYW4wMHU4TXh2ZHNRNGpNMGZTdXVDSlRIcVIxK3Zx?= =?utf-8?B?S0x4cjlFY01acS95cmRidjRKS2tpUGU1VnRzTDI2OUZFK2ExNG1vN0l0b0ZC?= =?utf-8?B?V2d1NGs2NkRTNlVhbU5NMUEvaXBwTkYvczluRWh5clNSQld2dEpEKzBZd0hX?= =?utf-8?B?ZXdEKzlHdHhsTXEvTmNqb2p5YUxad0ppZCt0U2lBN3pFYTdleHF3TmYycEg5?= =?utf-8?B?bGJRZm5kWnc4T08rMDZ5U1RJMHkxQ005b0p2aUpjUzdPMml5Z0Vvcy9YRkVq?= =?utf-8?B?RC9HMlNIWlpZVHV1Vjl3NnhtcnJBbGgyblJwVVcra3BKSkVYckl4eERqQnZz?= =?utf-8?B?Wnhic1pRV09QRnYxOVZkWDh4VVZCeTVUVTNjN1pURnFqT2p2b0hJWWZ6REFn?= =?utf-8?B?L2EyVFJsOXNCUyt1dE9tWXk5T2RUdHJVMDYyZ1NGVTZPLzNIREpmOWRxMVVk?= =?utf-8?B?TWpSb3orSWk1dW0yY0ljKzRkWjB5OHo5SWJMWFpXRlJzM1Ivbk5weVVVTyt6?= =?utf-8?B?TG9ZSnhtSDc0cEdVQmdlVEZzSVBVSTA0RWxCR093PT0=?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 5:wjyKmhKQqCP5IPEKMyarq2RzkrdWDY1cui6lpVV6FB3p/tyKVWNnikzxVJXcgfmzGgB8pymg5sx00R7+X0/qgk0X15LvzW0S6EsfYLDG032x2HUJSgrCH+A1giibXKROzh0O8XG0hTGKO322WEaSFA==; 24:S/OHPl8eTpDbRhCMpf+SP80cocF2jmqKT1oZOW63jyD3kuzfMXSJHT/9gYb66FRI4XRQUCx/pTdAtxR0wT5ZzRkrDUuvudexgitnjbyhz10= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2016 01:53:34.3345 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0921 Archived-At: Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 01:53:40 -0000 On 2016/03/28 23:13, Paul Hoffman wrote: > Having said that: if this WG adopts one *or even multiple* of the > proposals as Experimental RFCs. and even if just a handful of zone > maintainers adopt some of them, Mozilla could use those as input to its > own PSL. The Mozilla part is the easy part. Essentially, a script in Python or Ruby or some such would do the job. And once it was established, the people maintaining the PSL might sooner or later start telling the DNS operators "why don't you just publish a record, that would save us some work". The problem would be with the operators. It's quite possible that DNS operators would start adding such records if there's a standards track spec. I could even imagine them to be motivated to add the relevant records if there is *one* experimental spec. But multiple experimental specs? Not a splitter of a chance, if you as me. So I think we better pick one solution. I'd think my main criteria would be 1) any major DNS operator voicing support for it (or already working on something like it), and 2) as simple as possible, but easily extensible in the future. > I know that some people find this kind or resolution to IETF efforts to > be a failure. Because these could be input to the PSL, or to a popular > fork of the PSL if needed, I think this is actually worth our time and a > bit more effort. Doing multiple experiments may be a very good idea in some cases. It just doesn't look to me like it would work in our case. Regards, Martin. From nobody Mon Mar 28 20:55:45 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBF512D0B3 for ; Mon, 28 Mar 2016 19:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHnEUOYDUf6Q for ; Mon, 28 Mar 2016 19:09:27 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7485C12D0AA for ; Mon, 28 Mar 2016 19:09:27 -0700 (PDT) Received: from [192.168.114.1] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2T29PEf018545 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2016 19:09:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "Martin J. =?utf-8?q?D=C3=BCrst?=" Date: Mon, 28 Mar 2016 19:09:25 -0700 Message-ID: <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> In-Reply-To: <56F9E01D.4050007@it.aoyama.ac.jp> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> <56F9E01D.4050007@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 20:55:44 -0700 Cc: "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 02:09:28 -0000 On 28 Mar 2016, at 18:53, Martin J. Dürst wrote: > The problem would be with the operators. It's quite possible that DNS > operators would start adding such records if there's a standards track > spec. I could even imagine them to be motivated to add the relevant > records if there is *one* experimental spec. But multiple experimental > specs? Not a splitter of a chance, if you as me. Why not? If they only had to pick one of three, why is that harder than picking one of one? > So I think we better pick one solution. I'd think my main criteria > would be 1) any major DNS operator voicing support for it (or already > working on something like it), and 2) as simple as possible, but > easily extensible in the future. So far, this WG hasn't been able to do #2. And I'm not sure what you mean by #1. What is a "major DNS operator" in this context? --Paul Hoffman From nobody Wed Mar 30 06:47:11 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE0912D6B2 for ; Wed, 30 Mar 2016 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-PpzWb5KanB for ; Wed, 30 Mar 2016 06:47:08 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B853C12D658 for ; Wed, 30 Mar 2016 06:44:22 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id z68so61264403vkg.3 for ; Wed, 30 Mar 2016 06:44:22 -0700 (PDT) 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; bh=tnLIjluPZSitPFYzpaak/cpc8NuzUAzLqg9U2utn74s=; b=DDlYrOHLIZuBie8GrG022H7ktSNK3E8jmqnQiDzlVqfc0EWndggC5C48gyIwAc/8wb p2zS7kltzRKCeVNFWAI6nbjYjJ4tCkZfvmt3rW+0SY2+p1y4FlONvcLJKwaD5zw495J3 quuQWU6Sk07xQjVXMN1hiv1DJl186lO8zhExMxjEMzbZyUOWOV5UHUf3hvGGz4fp4b20 9/ce67B8q7D0MzPAWl81LeeoY8UVgdfati6xppu6xOAGbtYB5pf5hwYAGeAmlw8VIv2/ eh6mpp59Uam8KzariTUd88ywk/Qw02CMQjVZ3ahZNPjI6ez1m3hna1x5hUOC48nD5LZV IPig== 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; bh=tnLIjluPZSitPFYzpaak/cpc8NuzUAzLqg9U2utn74s=; b=aQwy7AfLGjjaYW3X9IApPlotlsagmjhjPk0zdvauP6KnrBF1sCMk9wp1WaI2k12ugx GFqSgD6QfMyU8Qv39DVIIqKJsOMWE+cteesmtD/JDDfAXd7hZy2rx4AiRo3+2pCcSLLs 81iCoO4wBzSH9OhttRZ3LSvcG5KxjRDqulfzYvDn5ukYEa2rSv5WDuRhDYsrmlruA4SD px4hTfNmHwzGA56zO1osz6ISvWmowrTA/WVncHr3j0TWK7j/JxdZBsnuYVFUfY0smLMl cTlLzVyMTpGTD8ZsuVzczNi5W95z+604nQ8guiZ8co02R/uRyrjzxhJNYLJElfM99UMu 0/Lw== X-Gm-Message-State: AD7BkJLaC0K8+TfTxCSrUpl546I5Yz/QnOQNf1gNjBHDIz4o6FttMbFP9IEtYXs6g59dPD9qI9PIcWRYEOluiA== MIME-Version: 1.0 X-Received: by 10.31.151.11 with SMTP id z11mr5126047vkd.131.1459345461842; Wed, 30 Mar 2016 06:44:21 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Wed, 30 Mar 2016 06:44:21 -0700 (PDT) In-Reply-To: <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> <56F9E01D.4050007@it.aoyama.ac.jp> <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> Date: Wed, 30 Mar 2016 06:44:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1140f86adb9c12052f44577b Archived-At: Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 13:47:10 -0000 --001a1140f86adb9c12052f44577b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman wrote= : > On 28 Mar 2016, at 18:53, Martin J. D=C3=BCrst wrote: > > The problem would be with the operators. It's quite possible that DNS >> operators would start adding such records if there's a standards track >> spec. I could even imagine them to be motivated to add the relevant reco= rds >> if there is *one* experimental spec. But multiple experimental specs? No= t a >> splitter of a chance, if you as me. >> > > Why not? If they only had to pick one of three, why is that harder than > picking one of one? A desire to interoperate, I would imagine. I would want to pick the same one other operators will use, and that other clients will use. Otherwise, to be sure of participation, I have to implement all three. -MSK --001a1140f86adb9c12052f44577b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
On 28 M= ar 2016, at 18:53, Martin J. D=C3=BCrst wrote:

The problem would be with the operators. It's quite possible that DNS o= perators would start adding such records if there's a standards track s= pec. I could even imagine them to be motivated to add the relevant records = if there is *one* experimental spec. But multiple experimental specs? Not a= splitter of a chance, if you as me.

 Why not? If they only had to pick one of three, why is that harder than pic= king one of one?

A desire to interoperate, = I would imagine.=C2=A0 I would want to pick the same one other operators wi= ll use, and that other clients will use.=C2=A0 Otherwise, to be sure of par= ticipation, I have to implement all three.

-MSK
=
--001a1140f86adb9c12052f44577b-- From nobody Wed Mar 30 12:58:57 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B0712D91F for ; Wed, 30 Mar 2016 12:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8aaZYYKiux1 for ; Wed, 30 Mar 2016 12:56:10 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D735312D919 for ; Wed, 30 Mar 2016 12:56:10 -0700 (PDT) Received: from [10.47.60.52] ([200.61.10.9]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2UJu41h018812 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Mar 2016 12:56:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [200.61.10.9] claimed to be [10.47.60.52] From: "Paul Hoffman" To: "Murray S. Kucherawy" Date: Wed, 30 Mar 2016 16:55:59 -0300 Message-ID: <2FB8DFE1-EF51-43A6-90E0-263D43F5A9E3@vpnc.org> In-Reply-To: References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> <56F9E01D.4050007@it.aoyama.ac.jp> <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Wed, 30 Mar 2016 12:58:56 -0700 Cc: "Martin J. =?utf-8?q?D=C3=BCrst?=" , "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 19:56:12 -0000 On 30 Mar 2016, at 10:44, Murray S. Kucherawy wrote: > On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman > wrote: > >> On 28 Mar 2016, at 18:53, Martin J. Dürst wrote: >> >> The problem would be with the operators. It's quite possible that DNS >>> operators would start adding such records if there's a standards >>> track >>> spec. I could even imagine them to be motivated to add the relevant >>> records >>> if there is *one* experimental spec. But multiple experimental >>> specs? Not a >>> splitter of a chance, if you as me. >>> >> >> Why not? If they only had to pick one of three, why is that harder >> than >> picking one of one? > > > A desire to interoperate, I would imagine. I would want to pick the > same > one other operators will use, and that other clients will use. > Otherwise, > to be sure of participation, I have to implement all three. For the scenario I gave (either Mozilla or someone with a fork of the PSL wanting to supplement the current PSL input with DNS records), implementing all three seems to not be a lot of work. We would only need to pick one if we wanted everyone to interoperate, but it feels like that idea is off the table. --Paul Hoffman From nobody Wed Mar 30 20:18:53 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3512D524 for ; Wed, 30 Mar 2016 20:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkgHZKM6omDe for ; Wed, 30 Mar 2016 20:18:48 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0115.outbound.protection.outlook.com [104.47.93.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5906F12D0C7 for ; Wed, 30 Mar 2016 20:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S2hAirT7Q88nIgdNX5X8g6yX6Lv2pcRWMtK/jR0fElE=; b=k/CqZum5ZpuAbaXmTAvXUvFOcoKA2QO4JsWK3drN5hYGUTQ6boTwsJr7QziCXavbOS7h3HQnFOERkof+i1xVNKlK/6kT7y0m8vDpMhk6GhLMKmYewXztmrOYXjO8D+WR2o4mQAKhZHB3hkfxU2N4ff9vkoQaE1MY9NzAlVcBxEg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [100.66.15.152] (133.2.59.11) by TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 31 Mar 2016 03:18:45 +0000 To: "Murray S. Kucherawy" , Paul Hoffman References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> <56F9E01D.4050007@it.aoyama.ac.jp> <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56FC9716.5000407@it.aoyama.ac.jp> Date: Thu, 31 Mar 2016 12:18:46 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.59.11] X-ClientProxiedBy: KAWPR01CA0035.jpnprd01.prod.outlook.com (10.165.48.145) To TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) X-MS-Office365-Filtering-Correlation-Id: 9da8add0-5c6a-4d93-fd9c-08d359132b4d X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 2:JXwOKvf3W1mnMgQFHezrykDuHEhWpfquwttHZCCNvpAA8V5N2jXMtwivxFXkf93FazHUy+qHMCctekzghw9S8btL2TGmblYn6A4NLaZ7iETW2P7+tXuRUDe35oJCiaAwfWmdn3mANzWbqsFpxlWK9s2inw+5mXiw4sX6Fea7OrThGaRcgYxnJBlVBzwRGXV0; 3:nCe3UJ4J5xrx/JCHkECBk0JDViD1xQF9sViqCe6/E3Zq4Vc5/c2hgOr9rzdKzteporIXH2g5GQsdm1L8dTlEO6zOhg65K4WdVCI41/+HilAFRdcHFdiaAcaT26ZuiLmZ; 25:TslL9+/QrS5nHh24thge3MdgkPovic+FKC3YgxRnhWR/03T6ZHrUkVBiBnOlb28XEpqsMD6pBscU4VjyXNASgUGb0mDP4N8TsC33wwDTfdBHVhGC0Zf1CzyYjgrkWEtpxYcEuH8JnzPVfo4fpjEGS5m1bFyjiYG8D8aJuDMbK8v+yBuRTk9Eqevxqel83yF5VqluAPXFQtIijMO/CVEaqlyqNfX4cm8byvezhu53b7tn9veMeWOmLsG2SKKJR8LZLO1xi6ELpHCOBpdTbVCTQnhieaCnXlSdRe8lpWuJqF/uPJmMFBInao5NG9Yic6xwAfY6tZP77Vrp531/jvCSMhDZ53Bb0TZ7ibnAy0ViJotHYknVBZIOXy34hfp76VgdScl6Uib49i0UGHQOIweXUv8CkvteLyVLrTETCqpAG7JW6JwYKtDGPtjoXFMA8UhGD4FcMVJX2sWc/qhq69TtnkNTRy3I7fbsU0Uy2RTjiZhQNoJstfW+UbjTqDB8hD5MKywwHIskCJMT8AbaUdrByE5M1nUPId5iONMr5GJtevqWS+r1i61YzL8VOgdV/owG8ZU+bU1EudKWSkQvG6UguKu+ITXoW8uuQrgdibLqVMw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0926; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6043046)(6042046); SRVR:TYXPR01MB0926; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0926; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 4:Z7zyyHQtaMIi1WNmcofy3zXqSujp8JrC9lvb/C/UsuBC+evMnyuZAlagoKiLrjWtGeKp6SQVkfTHL5d88LzPs7kB4G9F717HrfVrGRAtRHJPBeyg6bxgXluaZtCMXp0Xi68FbBX2IoCh4lSH3bZq+OZnkA/PgeM5VWIzCk+R5IprSZMhbPa13+ZLalMaK+guRFltOskozGjSF2D1YLv7hURIn79C0nGJ1Sg21H0/eoOav7CUJ5fxhShlx9bpUOgqZubssf7Ij7fwPLmx5WbFS1cUnCFa/9uwo7NulG06ixUkKeoNVRGF816AKjAYN/DEarNqs2UXhfSmxzZXI6zA477Tp0lElEjrypKkvh1OORLPBq+K2lSPNcGmmA0r4NtgCKkzyl5Mt6O/cVv8HvPV0POEW9ODz/olXQKQm7hWNwxYnQfAsblt+bJy+pk3E75i X-Forefront-PRVS: 0898A6E028 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(377454003)(24454002)(5004730100002)(74482002)(93886004)(5008740100001)(86362001)(76176999)(59896002)(65806001)(23676002)(65956001)(47776003)(66066001)(87266999)(54356999)(50986999)(65816999)(586003)(5001770100001)(1096002)(50466002)(19580395003)(2906002)(6116002)(80316001)(19580405001)(4326007)(2870700001)(83506001)(189998001)(64126003)(42186005)(81166005)(4001350100001)(92566002)(2950100001)(77096005)(33656002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0926; H:[100.66.15.152]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI2OzIzOkhIdmlYN3hlQjROYjNxWmluSDhpSUovTHR0?= =?utf-8?B?QXI5OHY2Ykk0SHZXOHo4MWZBdktjdC9ucjUrb3A3Uld6OFJBSFFRNWczcDRJ?= =?utf-8?B?VUY0MXQrUlpDNjRTZWh3cE95UjFyOUcwVzZaYkxUR21SbXJuQnltWVRxa2ti?= =?utf-8?B?ZFF5ZUY4SkVKSUgxMzBqL09wSlpwckFtWTJ0L1l0U3ozYzJsVFdkWnRtazl2?= =?utf-8?B?V1VvczU4Z2g3NTI1TDFWWVZOeTV4dTVmSi9oVzJyaTFXdmtyL2djMTAycUlB?= =?utf-8?B?QzljU2dZOWVlMEZPUFRPRVVSRlRHK0Z1WjF2WXIrbFM4QU85T2NzN2ExL1Fj?= =?utf-8?B?SlpoRlBtQmJucEF0QmFYTmlzS1JTUFZtcFJsSmF4TS9LN3RCRm9VVmd5SWpM?= =?utf-8?B?bnBXVk44MzIwV2gyWWJ4b2U1elZYMDBsNVZycFB5M2RjZHFxUDRjUVJDTTdC?= =?utf-8?B?eU9PZUwwRUdZRlRzWkpwclM3NW83bC9MMGM0blpJR2ptcmtpdXJLR1Zldm4z?= =?utf-8?B?aXZMd1k0WSt2bC96UzlzeEtYRmF4NnZ3T0lPQ0JoWFMzdktiVmpEOVl2akFo?= =?utf-8?B?ZElnZUF0ZHc1RFFoZndoWXhjS3R6T2NMb3hsUXc0Rmx6azFCcWxySVNZVURp?= =?utf-8?B?VEFuSCt0My82cENPTVQ2dDc4ZjVSakxsR3pTeDNTZXJWUzN5TXFTSjRBbkp6?= =?utf-8?B?UXozZmJRaFRXbGI4dUswSjJHaVlhMDczL3krTUpybml4YmlzRTgvQSt1amhH?= =?utf-8?B?TEs0UnN3cTFhMjVwSisvVDVidEhhUHdvL2pWaTdnc29KY01GRUZuKzQreFVu?= =?utf-8?B?amZlaGs5MXVCRGFsaThmWUpEczRoVzk3LzlTR3FCMlh5UWlhYmRYWU03dUZv?= =?utf-8?B?aGNWUXZvUWVmOTlpUC9oaEZBQU9OZDBkNEI3RHVQQ2dvZDYvQVE4azU5N09M?= =?utf-8?B?WEF6TUpxY1JKNUhRdTRZL2E5UEZlUlNTbzEyUDlhUnBHTi9PN0twVnBRQm0v?= =?utf-8?B?VnA1d1RMMWZhT1hBRlp5eFErTUM1T1BWRjZPTjVOVmoyVXg2Sms4NmF4NmdJ?= =?utf-8?B?QXVGNzhCOVNLZEt6Q0hwQUE2MU96QVEwRG5tb2FLeDhDTENEYUdUS3RLbzJy?= =?utf-8?B?NnozdnpsMmxSZFA5Z05sQTlUSGQzcFJ4aldDSHVNcjRBdnNOcnorUW9vWVJC?= =?utf-8?B?dWNleitMUlN0U2l6d1Z6NVRyTE1hZUIxekJuZ1kyK3pNNDduVnpWYWNtR3o4?= =?utf-8?B?SFhVVUNFRE1jUmV3V2RTQjNFYnNzVjIwMkI2TlBZZk5MaGc3U3R5WmZrdDFE?= =?utf-8?B?Z2FEdDhYQ2pIeCtHMHMzMjQxTCs4ZWNKU0NEeDFUUWt2bnFiQ1ZiTndkcFVU?= =?utf-8?B?L3ZuRXVWaC8vVVphWStqODVQdDM3MkxubG4ycEx6K1RYcG45c1hnRHJ4MitJ?= =?utf-8?B?eGo0RFBXWUVBOEpUZUlJUVlnM01HNUUzYjgvMHZUWU1qRGdORlFwWkgwKytt?= =?utf-8?Q?Rhx6D3klQB3VCsdKf8KkfiT1/6rYkCG7YpGDgZHRZD5o+C?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 5:/trAye58vDWb0/NE5PRDFoCO3+VL+8WUwMAvrCRlQduHqDUG72t4++Cj3czFjmYDZDOOmrQ5VkL3DtfKJ+uVLksfk0jyZm9xKaBEBc3mD8ZMug8VGIka5ohINmb5ULuBUMYVyRPpKVx124BqA30/ew==; 24:70h8e+A5Y8ikOdJIwHtWl9iX1CAqTi9nedHjf1ZH/+HhjpEbAoHJlZJXftnWOuxAv/lcUMbro8qB5gKrUjwg9bdYmM43Oa6b7EuiBCHaijw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2016 03:18:45.1716 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0926 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 03:18:51 -0000 On 2016/03/30 22:44, Murray S. Kucherawy wrote: > On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman wrote: > >> On 28 Mar 2016, at 18:53, Martin J. Dürst wrote: >> >> The problem would be with the operators. It's quite possible that DNS >>> operators would start adding such records if there's a standards track >>> spec. I could even imagine them to be motivated to add the relevant records >>> if there is *one* experimental spec. But multiple experimental specs? Not a >>> splitter of a chance, if you as me. >> >> Why not? If they only had to pick one of three, why is that harder than >> picking one of one? > A desire to interoperate, I would imagine. I would want to pick the same > one other operators will use, and that other clients will use. Otherwise, > to be sure of participation, I have to implement all three. Yes indeed. Also, increased choice increases the risk that the answer to "which one to choose" is "none" or "let's wait and see". Regards, Martin. P.S.: I agree that in the scenario that Paul brought up, implementing the consumer side isn't that much of an issue. What I'm talking about is the 'producer' side, including also the upgrades to bind or whatever software is used. From nobody Wed Mar 30 23:20:43 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46212D52F for ; Wed, 30 Mar 2016 23:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blR12uUEyA7y for ; Wed, 30 Mar 2016 23:20:40 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id CF85612D0AE for ; Wed, 30 Mar 2016 23:20:39 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.113]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DZ4Di3wfxW+uhRCQ--.56339S2; Thu, 31 Mar 2016 14:20:39 +0800 (CST) Date: Thu, 31 Mar 2016 14:20:35 +0800 From: "Jiankang Yao" To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Murray S. Kucherawy" , "Paul Hoffman" References: <473d619b6c614fceab703c34623afe37@NASANEXM01F.na.qualcomm.com> <56F8F033.40209@mozilla.org> <56F9E01D.4050007@it.aoyama.ac.jp> <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> , <56FC9716.5000407@it.aoyama.ac.jp> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2016033114193325730975@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart718823612726_=----" X-CM-TRANSID: AQAAf0DZ4Di3wfxW+uhRCQ--.56339S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZrW8KFWrZFy3tFWDGr1UAwb_yoWfXrc_u3 ykJr1DXa4fCr9agwnxtF4rtFs0gw4Y9F1rJws5Zwn5G345XFs7XF9Fgr9a9F1rKwsagFnx Grs7J34xAa4SgjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb3xYjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxMxkIecxE wVAFwVW8AwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvf C2KfnxnUUI43ZEXa7IU8RT5JUUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Cc: dbound Subject: Re: [dbound] On (not) moving forward X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: yaojk List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 06:20:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart718823612726_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KRnJvbTogTWFydGluIEouIETDvHJzdA0KRGF0ZTogMjAxNi0wMy0zMSAxMToxOA0KVG86 IE11cnJheSBTLiBLdWNoZXJhd3k7IFBhdWwgSG9mZm1hbg0KQ0M6IGRib3VuZEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtkYm91bmRdIE9uIChub3QpIG1vdmluZyBmb3J3YXJkDQoNCg0KPj4gQSBk ZXNpcmUgdG8gaW50ZXJvcGVyYXRlLCBJIHdvdWxkIGltYWdpbmUuICBJIHdvdWxkIHdhbnQgdG8g cGljayB0aGUgc2FtZQ0KPj4gb25lIG90aGVyIG9wZXJhdG9ycyB3aWxsIHVzZSwgYW5kIHRoYXQg b3RoZXIgY2xpZW50cyB3aWxsIHVzZS4gIE90aGVyd2lzZSwNCj4+IHRvIGJlIHN1cmUgb2YgcGFy dGljaXBhdGlvbiwgSSBoYXZlIHRvIGltcGxlbWVudCBhbGwgdGhyZWUuDQo+DQo+WWVzIGluZGVl ZC4gQWxzbywgaW5jcmVhc2VkIGNob2ljZSBpbmNyZWFzZXMgdGhlIHJpc2sgdGhhdCB0aGUgYW5z d2VyIHRvIA0KPiJ3aGljaCBvbmUgdG8gY2hvb3NlIiBpcyAibm9uZSIgb3IgImxldCdzIHdhaXQg YW5kIHNlZSIuDQo+DQoNCkkgdGhpbmsgdGhhdCAiQ2hvb3NlIG5vbmUsIHdhaXQgYW5kIHNlZSIg aXMgbm90IGEgcHJvYmxlbS4gDQogVGhpcyBraW5kIG9mIHBhdGllbnQgdXNlciBjYW4gd2FpdCBm b3IgdGhlIHN0YW5kYXJkIHRyYWNrIHNvbHV0aW9uIGFuZCB0aGVuIGRlcGxveSBpdC4gDQoNCiJF eHBlcmltZW50YWwgIiBpbmRpY2F0ZXMgdGhhdCBzb21lIHVzZXJzIChwaW9uZWVycykgd2lsbCB1 c2UgYW5kIHRhc3RlIHRoZW0gZmlyc3QsIGFuZCB0aGVuIGRlY2lkZSB3aGljaCBzb2x1dGlvbiBp cyBiZXR0ZXIgYmFzZWQgb24gdXNhZ2UgZXhwZXJpZW5jZSwgd2hpY2ggd2lsbCBoZWxwIHRoZSBz dGFuZGFyZCB0cmFjayByZmMgdG8gYmUgcHVibGlzaGVkLg0KDQoNCkppYW5rYW5nIFlhbw== ------=_001_NextPart718823612726_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
 
 
Date: 2016-03-31 11:18
=
 
 
>> A desire to interoperate, I wo= uld imagine.  I would want to pick = ;the same
>> one other operators will use, = and that other clients will use.  Other= wise,
>> to be sure of participation, I=  have to implement all three.
>
>Yes indeed. Also, increased choice incre= ases the risk that the answer to 
>"which one to choose" is "none" or&= nbsp;"let's wait and see".
>
 
I think that "Choose none, wait and see" is not a problem.
 This kind of patient user can wait for the stand= ard=20 track solution and then deploy it. 
 
"Experimental " indicates that some users (pioneers) will use and tas= te=20 them first, and then decide which solution is better based on usage experi= ence,=20 which will help the standard track rfc to be published.
 
 
Jiankang Yao
 
 
 
------=_001_NextPart718823612726_=------ From nobody Thu Mar 31 10:03:52 2016 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85812D67C for ; Thu, 31 Mar 2016 10:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROOPiNMM3tLw for ; Thu, 31 Mar 2016 10:03:47 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF6F12D667 for ; Thu, 31 Mar 2016 10:03:32 -0700 (PDT) Received: (qmail 67712 invoked from network); 31 Mar 2016 17:03:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 31 Mar 2016 17:03:31 -0000 Date: 31 Mar 2016 17:03:09 -0000 Message-ID: <20160331170309.40437.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <03217F5F-2A2E-47BF-BDFB-23A50008C440@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul.hoffman@vpnc.org Subject: Re: [dbound] On (not) reading documents X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 17:03:51 -0000 While it's great to see all this metadiscussion, is there any chance the discussants could read the three drafts and let us know what you think of them? R's, John