From nobody Mon Apr 4 05:39: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 EB43412D5E9 for ; Mon, 4 Apr 2016 05:39:09 -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 Y85y79ed7f5M for ; Mon, 4 Apr 2016 05:39:07 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5603312D509 for ; Mon, 4 Apr 2016 05:39:07 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id g184so94150375lfb.3 for ; Mon, 04 Apr 2016 05:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to; bh=/wS1g0R7T9aLDMhMJd9P1p5bSIooBehUwVkrcO1+p48=; b=ZM7PxgnUNsr/1s/TBs95PeeYE5hIqHu0vPCwEDAqbNCmgF/vTFaTbTLUSBp2iDQFmY E3CqvywpACGE+dtFqkJxp6y5u3upvrog3sALGm75i+faWvHeQ7Ez2ph5xLbe+YnwXFqx 6U8jAsesJ0bf82BjnsJEmT9s1Z6L2QzZYJebg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=/wS1g0R7T9aLDMhMJd9P1p5bSIooBehUwVkrcO1+p48=; b=FhRP4ciKLW7t6BjdeRQmtwWXyYEHUVDrgIl8tkHK5v/V6jMf4ByJSjNZZL1sn/G7TP SyaglQidg5bXwj4sjyczJQBeXqkhnEiAj0sdveBzVQ3rT7iTfMMbewLX4k19LzdONz5s Ar2T48013v2BE1rkh/eBIw0gQ2zvU/ew5jbpHTG8uVxou05pyzYT2WKBwzamILZFt0Hn BnVUuWmiLZPUnh3PmcOB63cM+ppZnWQtawbIZSCszbyOV7rh8kWdD251BLj3c3ChpqhW YDBnVucRr1S1rkqNjTTzasLOINnY845+soglsdCrsCCYXb51XMdLP0lA+yRt9rIfxTfo AAPA== X-Gm-Message-State: AD7BkJJkreKDAK+nXMVmSw+6sf4agBzrDRPCH/0l0QBedXHS2ga1yVR98jKGBAGA54h6M6FSM23GkaHt1Agjxw== MIME-Version: 1.0 X-Received: by 10.194.59.138 with SMTP id z10mr17642234wjq.74.1459773545285; Mon, 04 Apr 2016 05:39:05 -0700 (PDT) Received: by 10.194.67.132 with HTTP; Mon, 4 Apr 2016 05:39:05 -0700 (PDT) Date: Mon, 4 Apr 2016 08:39:05 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86c8c09ea7dc052fa803c0 Archived-At: Subject: [dbound] New version of draft-deccio-dbound-organizational-domain-policy 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, 04 Apr 2016 12:39:10 -0000 --047d7b86c8c09ea7dc052fa803c0 Content-Type: text/plain; charset=UTF-8 Hi all, A new version of draft-deccio-dbound-organizational-domain-policy has been uploaded. References: ---- Name: draft-deccio-dbound-organizational-domain-policy Revision: 02 Title: Organizational Domains and Use Policies for Domain Names Document date: 2016-04-04 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/internet-drafts/draft-deccio-dbound-organizational-domain-policy-02.txt Status: https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/ Htmlized: https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-deccio-dbound-organizational-domain-policy-02 Key Differences: ---- Note that the biggest change between version 01 and 02 is the elimination of the "_odup" TLD. Instead, policies are published from the TLD and below. General Notes about the Approach ---- The mechanism can be thought of as "policy" delegation. Policy begins at the TLD. The _odup sub-domain is used for that, e.g., _odup.com. Until the point in which policy is delegated, policy is below the ODUP name at hand (e.g., _odup.com -- where "com" is referred to as the organizational domain). Policies are either delegated either explicitly using "+org" directives or by "relegation" using "+bound". The former is like the use of NS records to delegate namespace in the DNS; the latter says, "there is an policy delegation boundary". In either case, the result is that policy is now handled by a new organizational domain. The defaults were carefully considered to match existing behavior, including cookie use, wildcard use, PSL use, etc. One of the important points is that child inherits policy from its organizational domain by default, so every name doesn't need a policy (i.e., it gets it already from its parent). But it can have its own policy, if designated. Or it can become its own organizational domain, if appropriate, using "+org" or "+bound". The PSL can be used to build ODUP policies, and ODUP names can be used to re-construct the PSL. This was primarily designed both for backwards compatibility and for smooth deployment and transition. There is code to try this out here: https://github.com/verisign/odup Please review and comment. If you have questions, please let me know. Casey --047d7b86c8c09ea7dc052fa803c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

A new version of draft-deccio-db= ound-organizational-domain-policy has been uploaded.

References:
----
Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 draft-deccio-dbound-organizational-domain-policy
Revision:=C2=A0=C2= =A0=C2=A0 02
Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Organizational = Domains and Use Policies for Domain Names
Document date:=C2=A0=C2=A0=C2= =A0 2016-04-04
Group:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Individual Su= bmission
Pages:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 23
URL:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-deccio-dbound-organ= izational-domain-policy-02.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/dra= ft-deccio-dbound-organizational-domain-policy/
Htmlized:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft= -deccio-dbound-organizational-domain-policy-02
Diff:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http= s://www.ietf.org/rfcdiff?url2=3Ddraft-deccio-dbound-organizational-domain-p= olicy-02

Key Differences:
----
Note = that the biggest change between version 01 and 02 is the elimination of the= "_odup" TLD.=C2=A0 Instead, policies are published from the TLD = and below.

General Notes about the Approach
----
The mechanism can be thought of as "policy" delegation.= =C2=A0 Policy begins at the TLD.=C2=A0 The _odup sub-domain is used for tha= t, e.g., _odup.com.=C2=A0 Until the point i= n which policy is delegated, policy is below the ODUP name at hand (e.g., _= odup.com -- where "com" is referr= ed to as the organizational domain).=C2=A0 Policies are either delegated ei= ther explicitly using "+org" directives or by "relegation&qu= ot; using "+bound".=C2=A0 The former is like the use of NS record= s to delegate namespace in the DNS; the latter says, "there is an poli= cy delegation boundary".=C2=A0 In either case, the result is that poli= cy is now handled by a new organizational domain.

= The defaults were carefully considered to match existing behavior, includin= g cookie use, wildcard use, PSL use, etc.=C2=A0 One of the important points= is that child inherits policy from its organizational domain by default, s= o every name doesn't need a policy (i.e., it gets it already from its p= arent).=C2=A0 But it can have its own policy, if designated.=C2=A0 Or it ca= n become its own organizational domain, if appropriate, using "+org&qu= ot; or "+bound".

The PSL can be used= to build ODUP policies, and ODUP names can be used to re-construct the PSL= .=C2=A0 This was primarily designed both for backwards compatibility and fo= r smooth deployment and transition.=C2=A0 There is code to try this out her= e:

Please review and = comment.=C2=A0 If you have questions, please let me know.
Casey
--047d7b86c8c09ea7dc052fa803c0-- From nobody Mon Apr 4 10:57:07 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 1DF8E12D162 for ; Mon, 4 Apr 2016 10:57:06 -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 V9gmb8V6nlrA for ; Mon, 4 Apr 2016 10:57:04 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 CD9CB12D1AA for ; Mon, 4 Apr 2016 10:57:03 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p188so155456129lfd.0 for ; Mon, 04 Apr 2016 10:57:03 -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; bh=HiwoByUYePRPIXxf0AS7yzSB+31ldwdaHoJ4ezUjgrs=; b=Om7ktTS9utp+K/Tmn9JocgwXZc9NqwgIAL/Uw/HfbtjyzcttIr3cUv32vHouV1AAJX j8vPW4tArlz3eylNoNye/Ns+QAbIvKLXoEL5jb2zvedf8v/E5UIJGD2NTzDWDnVVISEs YkwaRnNuAE83hfqiUQYonYtQrOm3htPN7BJWE= 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; bh=HiwoByUYePRPIXxf0AS7yzSB+31ldwdaHoJ4ezUjgrs=; b=Ifm9TX4MiPfFljxMJh0mkNAK4pAINyYgyaGuv9Hdsex70WfgKJYTVo3vYhMq7l1HI1 Lke1PAFg/0xAy/dgZM8twfmIzCg4MekgKUW0wM4msG5NoT/i3ffMu9V8jobYoRvMFErL +NRUwvUzWyIE1Lyhfp3P03U31hm4Pt3nAhkCRrcEc9r8cMA0XwMpVFoxQckwKXsOZGwj vuKLMruNxtW2KmFM4szru/SfGDJhKTLcv7xlhbRm8vC5VGIHafEYquaHMLQiQXKlR2Dv uZURlH2DuGwjtBr0JSz8st/RYIptjEbIwROt3C/EIxM/eNAFjb2W+XYzDb0douvzIqL4 zW/w== X-Gm-Message-State: AD7BkJLcylJOVImwt1aD+8Fgg/EYBSnRkN/gBYM0swJtQ9elgBPZN0cWpc1tS8IGikm2ryPKEJ1ElpTvgR7J+w== MIME-Version: 1.0 X-Received: by 10.194.205.138 with SMTP id lg10mr19519727wjc.153.1459792621855; Mon, 04 Apr 2016 10:57:01 -0700 (PDT) Received: by 10.194.138.169 with HTTP; Mon, 4 Apr 2016 10:57:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 13:57:01 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb70a1eac067d052fac7468 Archived-At: Subject: Re: [dbound] New version of draft-deccio-dbound-organizational-domain-policy 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, 04 Apr 2016 17:57:06 -0000 --047d7bb70a1eac067d052fac7468 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 8:39 AM, Casey Deccio wrote: > > Key Differences: > ---- > Note that the biggest change between version 01 and 02 is the elimination > of the "_odup" TLD. Instead, policies are published from the TLD and below. > One other difference that I neglected to mention is the addition of the "+fetch" directive. This directive makes it possible to advertise that a set of policy statements for a given organizational domain may be downloaded for local reference. This also enables creation of a PSL from ODUP statements in the DNS. This is demonstrated in the odup2psl.py script, which is included in: https://github.com/verisign/odup Note that another script, psl2odup.py, is used to do just the opposite: generate ODUP from PSL. Regards, Casey --047d7bb70a1eac067d052fac7468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2016 at 8:39 AM, Casey Deccio <casey@deccio= .net> wrote:

Key Differences:
----
Note that the biggest change between = version 01 and 02 is the elimination of the "_odup" TLD.=C2=A0 In= stead, policies are published from the TLD and below.
<= /span>

One other difference tha= t I neglected to mention is the addition of the "+fetch" directiv= e.=C2=A0 This directive makes it possible to advertise that a set of policy= statements for a given organizational domain may be downloaded for local r= eference.=C2=A0 This also enables creation of a PSL from ODUP statements in= the DNS.=C2=A0 This is demonstrated in the odup2psl.py script, which is in= cluded in:

https://gith= ub.com/verisign/odup

Note that another script, psl2od= up.py, is used to do just the opposite: generate ODUP from PSL.

Regards,
Casey

--047d7bb70a1eac067d052fac7468-- From nobody Sun Apr 10 10:31: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 C5D3F12D61A for ; Sun, 10 Apr 2016 10:31:13 -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, FREEMAIL_FROM=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 Lj0ttBQw884R for ; Sun, 10 Apr 2016 10:31:12 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71CAA12D095 for ; Sun, 10 Apr 2016 10:31:12 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o126so161360275iod.0 for ; Sun, 10 Apr 2016 10:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=x5HrCYSHFiuR5MdvxPe1kbloPGPufufKr4YbCzMGdNc=; b=KnTlDXUfraXc1d+49KmMtuTdxyDrGc/9G0aWkewoitnQ7nhUUxkw6+T6TbqLh8/5Fn /Q37qFHHaX4p18LCH/EsJRnZ7zFtXHIIN5QHo0uys1j2Z9hlIyDoh7scYdNvwd0vviFM 9sX0K6TrCYBLKvSa2nUn7YXOX5qShP4/Y71+b/yDh9wUexxhrZrMlf3vwOrE/rh3RWLY RL48a2alZOo9syfJAH3Zh3PfShcZ8QduCNMiLBYXTEim3Y5praWh0y9tfGzJHenwsiam 6UjwRYvGb6byzRVZ3jdiQWePU4vdOvwndcDt9euKekpRDR3id/fgZ/Rqxd8C9fWNk2tN 3ANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=x5HrCYSHFiuR5MdvxPe1kbloPGPufufKr4YbCzMGdNc=; b=UWXKiSijMGK9sh+bIolXq1Puc9u2G+x15S6TABzRVsyFauzjSJMucjw2+XqPChYdNP BpAzRmyf9aVyAK2yax37W468HrDICjNUDwcT4YdZBW9EgbsPR1wTEk9LiK7sfhKXouIV O7Se+My1Vldt2wwdGzIhBRut1x6Te02tVPfMkEHmsnfvcrX00aXMM3yBErERvSPdb9CF FaAYsnc7S2HDJSl26R80MLZFdxzq1rjTiOkg+Bc64xeSR8lel/iHrjKn0h0/jwUHf1R9 fcRkW+68N9nij5jgXobcFatr9HsmsHEceIfo7Fu/VBAWJHyTaeznR1iKpwqQxfdC3vt5 b+xw== X-Gm-Message-State: AD7BkJJmxiAVgOIUHKFf6Hb/twK+yw/JvQL4JBLg/MqVVq6myVBIp5PQdEJg3BiS8i+2CpkzRpagz0ir9Za0ng== MIME-Version: 1.0 X-Received: by 10.107.150.8 with SMTP id y8mr18663484iod.66.1460309471843; Sun, 10 Apr 2016 10:31:11 -0700 (PDT) Received: by 10.36.193.133 with HTTP; Sun, 10 Apr 2016 10:31:11 -0700 (PDT) Date: Sun, 10 Apr 2016 13:31:11 -0400 Message-ID: From: Jeffrey Walton To: "dbound@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dbound] Requirements for administrative boundary data sources? X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:31:13 -0000 What are the requirements for the data source? I.e., does it have to come from DNS? From nobody Mon Apr 11 01:19:32 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 75F3312E8A4 for ; Mon, 11 Apr 2016 01:19:31 -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 oNfxuQ6lh_4J for ; Mon, 11 Apr 2016 01:19:30 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0136.outbound.protection.outlook.com [104.47.92.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DB812E8A3 for ; Mon, 11 Apr 2016 01:19:29 -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=6CbLa41vUNCZOfuxgURD/qIvXcI6n9oRTOnewccBy9g=; b=HnN/tKkTPlHZzpt/b9PLFgAlWX8L8/HcEaggNpSzPdYJTZ91R9xSAnPsGf/nqcNYodpTgCcsvhuEjKfRQgrzGjlSmP2Onx1s4WWGXeL8Q5JiiSvWBLGw5nvpDxjBr+5UiTffzIFTF7cUNdu/2/GJTY/a8B2lj1hZgKMX+xe4Frc= 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 TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 08:19:26 +0000 To: , "dbound@ietf.org" References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <570B5E12.6030909@it.aoyama.ac.jp> Date: Mon, 11 Apr 2016 17:19:30 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 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: TY1PR01CA0022.jpnprd01.prod.outlook.com (10.161.131.160) To TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) X-MS-Office365-Filtering-Correlation-Id: 1cde27db-dd95-444b-0a58-08d361e1ff6b X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 2:hNNnbEDSseY55ZJ3OsO7CVTSg1Yrn0Bos0xnGJm+BxQtDnXTbLs/k17vdPf2gu/H1Ii7ld5kxQ8oNnzC7K7IjpuGlslFrYNTtaw5YmctxG+vjMQOBnbz8v8iSPm1oVytjI1/fLs1lCRIiDPiNU65pQemLZQBaUhT8mdZnc26dbE6xBcIYpTjo7UlPyyNLknE; 3:Lq3cXaa6FMKzvcXwMVaNmbwwg0t7NFc8Lo8B988U1ug4sn2kXM0MK9Qco3+5IMmRnN/XuwLEhJe0l7Thpnnq3s1ta2hhEyaPO4rlT5z/2HN5FGZHQbCOTconFTu0R1XQ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0926; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 25:v7dBIH8v8Y4x4GGpUBh0E8jJsG/xe+j5+nkU1Ld8NlIIfkJt6CixTKbQIfjvo2WAprdLAnpH7Z15L1J0PllKrWmH7ox+BQk1yS4xj7oZOgO14Jwz86XoshkQcGj0DymUDf3lfweH1+Ng9NS90JZnVyhcR/G1fgqqUcpJ3eyaHromJyEkdagjWWshJCXQ4mL4dTD8O8Ju2K5O+MzaBanLn6DqV9SFy/rKcp+5I57R3z17tyMERvt+1u4qSvE4PuJfd+Nca1u6HXN1Elim5Wr+ej2ltcDQV3vDgHfp8fT0gSUsiMTlVrjC1q6XIgxHjmDDjamRV+Cz+BzV7D60PVnjGRA+UCVZx1A4OsvupiHi4FVZo5y4W5BFAAnsGPi6R8/o9YFGFykaKYD+paD9JocaRtDzt+d9gaDh/65+crKQoexzykANsLJwuQKv4/lCvopLRQ+37xdzuXM6Qg7IOjIi0TAp3ELlfUhOcxiiz6wUwdgQLmfStiFUkbzVQw5iT4RT+DEykhPXtorS0ebxh5WRl6jaYRqfOdk8pBnRQeM/AGYBsLntVXBIHG0C3h0Q1Rmz9cTjb42VDNVu527qeCqu+rYmxcyZq1VqE0iZGamBReSfMzOglQdgJ2tkvfkGtE0NaIeFWaG6CiMfJ06MiOz/fg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040074)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046)(6042046); SRVR:TYXPR01MB0926; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0926; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 4:R+59FAJJNzJYad7iKiX7m+tGRJxYdRm05NR5meIrN7ZQuCYL6QV6Or1pTJK2gZZd/Uu17eLuBqBVRLYKQXQSxkrKlpT3BjaMpJTbhfSPtaXl2t8b1Q72K9UfwxpRIm6aMN1kcLKurxc/pmTDAhRyEiQSECPtjjmpUM4p+/Of1lBUAzdioiV6cpa21JHs6dZDVs01PpPUSP8oz2GG9cg0oCjTixdgKWIW/gzDH3wps5cbiRWcjJgK4FCay5/PYNT2btRc+hQo1k9gBYWzKEaT1EhXP+4RGV/JW+i5xG5L+cRiYOzAt1iw0kZQWsj/vunvvRlc9St94ocd8LQBRBGtK794IAACWi+7NualdSFzlXt2Hto97d6yJQAyQLQHfU6cG8hH83VpnNy98G9tR9q6tpgoqxPuj4OL/YeIg4VSNFGhEoFxiX2q92vdJDVILubt X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(92566002)(23676002)(83506001)(2950100001)(81166005)(2906002)(50986999)(54356999)(87266999)(76176999)(65816999)(66066001)(65956001)(47776003)(65806001)(42186005)(33656002)(2501003)(586003)(5004730100002)(3846002)(50466002)(77096005)(189998001)(64126003)(4001350100001)(230700001)(74482002)(80316001)(86362001)(5008740100001)(5001770100001)(107886002)(1096002)(6116002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0926; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI2OzIzOm5kaDViY3dZMEltbkpEckJWbnhiNUE2cnhT?= =?utf-8?B?eGgzZDdReFZYdFFvV2JZSmdBZHdyUTNNZ1lSMEhZWnhyRENBZEVTdDlBWWpR?= =?utf-8?B?cHVwM2ZOUmF5ZmhGcFlONWhDbDZ0WFN0cW9CdTF0VjVyZ20wU2xRdllta043?= =?utf-8?B?bTdlbzhRaEJub24xb05oSzd3RlA3QXNYSFMxdHJRbWJGT3ZWdWhLYk4xVVlU?= =?utf-8?B?ZWpQMXRheXpnUWZBVkNXT3FvUS9lQWwwdDhJQkdRMUpUOFBsZk1HeUxSejRJ?= =?utf-8?B?R1Bpbzk4M2FidTBwVDI1VG5mQmJ0b21hbGdhZ1Yxb0xjVXBaeWRSb0RiSmhp?= =?utf-8?B?c3RBMSt2WUg0eUlLbUVIMkU3Mk5kSkhIeEZFZEJaSlNrS0Z6SkRKRUtIVlZZ?= =?utf-8?B?RUN1QjByOXVwSGl1NFFlY3UzMUtjdVlJQ1F2V3ZoNFBUcy9uN2RRVmVUSUpr?= =?utf-8?B?WUdmRFMzNXV5Y0FId2o3ZVoxZ3BiWnI1YndmSVFlZDIzMDZSVTF3T2dBcnYz?= =?utf-8?B?dlhidWQ2WlpwdEcwbFAzd3lGZGdkRjk5MVROMk16N1pMWGQzTnhKYkswaGdR?= =?utf-8?B?bUpaMmJwUmNDWFgzc0VlR053d25rYnRmaEJTTWFxSHlZNEg3OGswdlkxM2VD?= =?utf-8?B?ZzM3QUVqMmlVV3J6QUd3Y3ZkamFjVk45MjhxZm42RTNxbCs2UlBWeVVFWHJS?= =?utf-8?B?dEViRTEyaDR0czhYTFQvZ0VlNFBZUmZCZllQTmJFM0pJMUxnbkw1MXdicW1j?= =?utf-8?B?aFc0YmY1NTdpN1h3MEVrVitBNG5wcXkxVm5iRGV0QXpuYzNkaGJ5Sk1rRVZz?= =?utf-8?B?eXZnS24yR2VrQXVOK3crbE5JWm55ZlowYkk3dUsvbUhzOWlvZmsxNEVsUnll?= =?utf-8?B?eEgzVzBqOENoak54Vk5QTE1xZ3IxKzBhM0xZN0syQ2dzRmRhcWpOZmduemdE?= =?utf-8?B?c0VMUGxmNkxhTzYySVpUS1ZoV2puRmprbnBvcXlUNkJTUWhYbit2QkpFTnJ3?= =?utf-8?B?VmpsYnlNN0JkYjdjZDFDUC9PeWxuM3dFMUVtQTc2Y1JkWDhLQ0oyZjgxMW80?= =?utf-8?B?TGNteHJsM0t2TE1uTXkvK3ZIakl4MEVhZ2ltSHA3UThTUnoyUUxpcjFaSE9L?= =?utf-8?B?dnRxd3cvc1l2V01tWHg3Uzh4dVBGYnZVVm5GL2pKWExxdEp5S2RDbGhrNkJU?= =?utf-8?B?ckxMTVFORVJIeTFnWnp0QVZlUDJUVkVGVzh2cFJXZ2dpcXNRZTdhVzJLMHNQ?= =?utf-8?B?aGZGdDhUYlJaMFhSYU5PR0diL0JRUVNLKytLWmZyd2t2VEs2YUM3S0R3UGM4?= =?utf-8?B?SEswSDR6K2daKzd3K1dISGFKMXF4WHBScWlMUWQvb2N5c0VMcFhIeHZQSEdY?= =?utf-8?B?L2FqMVVLUGFob2NiRXdnZ25FYjRsTUlZdWVKOVJsSjJjWG50RFF6VmNwVHA5?= =?utf-8?Q?+8snOE=3D?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 5:RxpSfXzoITODJJDyQx5BDP3dS7ntMkpbllKW9m2xiKo1c0eKdB22GwnsklOBjKlpD9E8affTs3yJXokisuBi62xCNiqNIFGH9OVxXGnNCp+AU38uO9cxFvSQDsjkcKo6qkFSnG4D/ZhLXgrToS3iqg==; 24:gr7ebhFMnPCpSWg+TuqZRizw8bhCl/fVBJO+tQDTGpv7F1bCqFcmGQU4pA4moyr0MnVeC7E+mPlrabE9SP+AG6iFMyjEK5uXSiJchk0Oagc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 08:19:26.8549 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0926 Archived-At: Subject: Re: [dbound] Requirements for administrative boundary data sources? 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, 11 Apr 2016 08:19:31 -0000 On 2016/04/11 02:31, Jeffrey Walton wrote: > What are the requirements for the data source? I.e., does it have to > come from DNS? Not necessarily, as far as I remember. But one requirement (or at least desideratum) is that it come as directly as possible from the actual entity that's in charge. That property would be met easily by DNS. Regards, Martin. From nobody Mon Apr 11 01:35: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 78B6F12E928 for ; Mon, 11 Apr 2016 01:35:06 -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, FREEMAIL_FROM=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 1cGvI8aDt8Rb for ; Mon, 11 Apr 2016 01:35:05 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3DE12E927 for ; Mon, 11 Apr 2016 01:35:05 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id gy3so55507303igb.0 for ; Mon, 11 Apr 2016 01:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=X3j9xE4h+yG4x0VAw/QVyDHOMHfAPpnG/G6cTojMjkg=; b=cK8mZmCLl/MMOVD7btMrcmPEfujiQhnrp/mhrFPX3i/D6FK6MUAy6q7hx1UZCcnxgA r7UeTJMgZahP/TfuaTl6ymCzEX5LPt/Om80otLdrcyfu6elpC7QIqF/KSZumEcAfyl/4 5hgGXWGBKGr+/RHmGIqFwB7gnt7l8tdaZxcZsoFT4/9WBRkfC08Y0NyezF+u3V04f7I0 ft9Q0tglCnlzi9RSwS1Zd/7Z+o+OQ+CqNz5pqGdxSo7fF8dxErJfQ4FLdIpVmRhGiJb9 kqtwkDwMRbeG2yFdBtsG+1gmlnBLNqbyx5GRWBCz+FEFALFJUmXzTdWxFc/Eu68MJwy7 PYww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=X3j9xE4h+yG4x0VAw/QVyDHOMHfAPpnG/G6cTojMjkg=; b=IGHKHRQuQuBbl5T4Wq+sQY+zH7PBHENpZdfsmxcH7YPcIS5iciBJWZ61t6F9dbOBqj WizwBYhDtgnVdR5U/+pNZLMnw3cfJ7IsWQ+EaHzvw0Qn0S2XmtntyPvCnqZu9H4YYhjR woDOsh4LY3Bv0LFt/KpOK2wcaoYg78KsIES0Idqmfxh9trr70kZXx2x4orAWcAxmY1Sg b4kG1eDrBQlN5k9F+lOpjPZ3PZSyn1spevTqNDN4qKnzZAqbdZY1sY6nyuyMxbgwa1y2 U0La3H1ay1lqzeNrlZF2y2Qj0YIY7DrGmsfV/H6/u6zweysB+L6tydLNQrqni7RkvhcO CttQ== X-Gm-Message-State: AD7BkJINjUd03TmnBPdKv1DZEKhKGbxO4FeFDhUmcv6hhRm/Spo0BYAO9o0euVx4nsEv+BiW6Lj5XQcdfpTAeg== MIME-Version: 1.0 X-Received: by 10.50.124.36 with SMTP id mf4mr17112291igb.92.1460363704597; Mon, 11 Apr 2016 01:35:04 -0700 (PDT) Received: by 10.36.193.133 with HTTP; Mon, 11 Apr 2016 01:35:04 -0700 (PDT) In-Reply-To: <570B5E12.6030909@it.aoyama.ac.jp> References: <570B5E12.6030909@it.aoyama.ac.jp> Date: Mon, 11 Apr 2016 04:35:04 -0400 Message-ID: From: Jeffrey Walton To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Requirements for administrative boundary data sources? X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 08:35:06 -0000 On Mon, Apr 11, 2016 at 4:19 AM, Martin J. D=C3=BCrst wrote: > On 2016/04/11 02:31, Jeffrey Walton wrote: >> >> What are the requirements for the data source? I.e., does it have to >> come from DNS? > > > Not necessarily, as far as I remember. But one requirement (or at least > desideratum) is that it come as directly as possible from the actual enti= ty > that's in charge. That property would be met easily by DNS. Thanks. If the PSL is moved into owner/operators web services and out of DNS, then it may be easier to build a new system (say a PSL.txt like a Robots.txt) rather than retrofitting (adding DNS infrastructure and pushing record changes into DNS). Jeff From nobody Mon Apr 11 10:03: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 974F812EEC4 for ; Mon, 11 Apr 2016 06:34:50 -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 89-KrhYtkq4D for ; Mon, 11 Apr 2016 06:34:49 -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 ADE3812EEBD for ; Mon, 11 Apr 2016 06:34:49 -0700 (PDT) Received: from [10.32.60.122] (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 u3BDYlEE097005 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2016 06:34:48 -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.122] From: "Paul Hoffman" To: "Jeffrey Walton" Date: Mon, 11 Apr 2016 06:34:47 -0700 Message-ID: <8B580AD0-E10D-42C5-8806-AFA5291FD29D@vpnc.org> In-Reply-To: References: <570B5E12.6030909@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Mon, 11 Apr 2016 10:03:58 -0700 Cc: "dbound@ietf.org" Subject: Re: [dbound] Requirements for administrative boundary data sources? 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, 11 Apr 2016 13:34:50 -0000 On 11 Apr 2016, at 1:35, Jeffrey Walton wrote: > If the PSL is moved into owner/operators web services and out of DNS, > then it may be easier to build a new system (say a PSL.txt like a > Robots.txt) rather than retrofitting (adding DNS infrastructure and > pushing record changes into DNS). The distribution of the DBOUND information is not nearly as important as the collection of the inputs. If DBOUND specifies a distribution using X, it should be trivial for someone to collect that information using X and repackage it in Y. As Martin points out, the most logical way for the owner of zone to say the zone's policy is in that zone or a child of the zone. To me, that's the most important part of the DBOUND work. --Paul Hoffman From nobody Tue Apr 12 12:46: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 D234812D924 for ; Tue, 12 Apr 2016 12:46:17 -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 mRv1rnbYB753 for ; Tue, 12 Apr 2016 12:46:15 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 B2A3912D862 for ; Tue, 12 Apr 2016 12:46:15 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f52so25335165qga.3 for ; Tue, 12 Apr 2016 12:46:15 -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:from:date:message-id:subject:to :cc; bh=hWhuATLVP2sx+ldGCwOHDvDueWJLETc721aEZv9DSQc=; b=W8BB1tdEls0WZrW7bbX/panL6M0cmBKSdvWSUdcnU49gGpRQMN1PuXR5zuNBP0HXTv mJNSVtxV+BS11g9g284alG7ZRItQhbWOqfPOYOdkW7vVKtsxUtk3D6K93t250kHo9yjm Tx40TltkD773EBWqcBLUzef5pB4gokX3azhAWvxw76cvqS5DCGUOdHsHclVcI/bQJRtC SAtR/2Mls29D/FbwfMsRRD71tmfV2xN6WEzbfeKsj3iUg1eopsNHKPy6O16hiNNNZMKT pokzHlTU9t6/DNFQYspDYokVMuo8FyvwlsvzNEzSfe+yGlllhBBIox2JqgPsvEQ/Rc4c xoCw== 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=hWhuATLVP2sx+ldGCwOHDvDueWJLETc721aEZv9DSQc=; b=ROTHb/lY5drVocAIVt3T3O2+GKXsgG49rckGoKyfs7TeBfzoDHJBho9xgyRWAB54HD qMOc9n2oEzCtN8xmu9OkaAOog5JYDgOobPMIkGbxCZQRbaCU4QK7JEpX73vc0Q0nZ0SU LN0TB96QQPYRgsyVQuJoWocj8c+UdEzJY4F1OdHBlT8h4YePTEcYEzyPTv8Fh9HfbLmU hhRcG/7PY8BWlFFZqIyB0+p+B47JRSo9mt5Nnpm7kEVSfMtvsE/0snKlo9UqPbJe19WS 2WhnGdr4M+YcoQWFsoG/TJHUQ01I6d1JRzXQPVrPULG4l4a9fowWpoEuH7K0DXBZv3nf Rh/g== X-Gm-Message-State: AOPr4FW7br3ecJKJNXNwvX5xCtWl4anTX4uaFWle8T5Zwa14oSJE1oT11gweyBWCmk/WoipnceDc3SgX40lmaw== X-Received: by 10.140.152.78 with SMTP id 75mr6357756qhy.22.1460490374787; Tue, 12 Apr 2016 12:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.70 with HTTP; Tue, 12 Apr 2016 12:45:45 -0700 (PDT) In-Reply-To: <8B580AD0-E10D-42C5-8806-AFA5291FD29D@vpnc.org> References: <570B5E12.6030909@it.aoyama.ac.jp> <8B580AD0-E10D-42C5-8806-AFA5291FD29D@vpnc.org> From: Jothan Frakes Date: Tue, 12 Apr 2016 12:45:45 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1135a35afccc3005304ee925 Archived-At: Cc: Jeffrey Walton , "dbound@ietf.org" Subject: Re: [dbound] Requirements for administrative boundary data sources? 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, 12 Apr 2016 19:46:18 -0000 --001a1135a35afccc3005304ee925 Content-Type: text/plain; charset=UTF-8 > > > As Martin points out, the most logical way for the owner of zone to say > the zone's policy is in that zone or a child of the zone. To me, that's the > most important part of the DBOUND work. > > +1 also As one of the contributing volunteers on PSL I can say this is important to us as well - that these policies be defined by the registry for 'top down' TLDs that come from IANA delegation (we follow ICP-3 - one authoritative root). Some of the biggest challenges that the volunteers have are A] multiple, conflicting requests from the same registry, B] ensuring requests are from the authorized source, and C] if a request comes from a third party - validating the request with the authorized source. Having this done in the DNS zone would eliminate all three issues for us within the IANA chain. That said, we also recommend any solution be designed to not discriminate, nor have any opinion on innovation below that, such as done by Amazon, Microsoft, Google, Github, Centralnic, Dyn or the many others who subdomain or what they do - and encourage that if there is a top-down solution that it not introduce burdens, walls. fees or gates where such innovation might require blessing of the parent in some form. We record changes the balance between these by maintaining two sections within PSL, "Public" and "Private", respectively, as described above. -Jothan --001a1135a35afccc3005304ee925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

As Martin points out, the most logical way for the owner of zone to say the= zone's policy is in that zone or a child of the zone. To me, that'= s the most important part of the DBOUND work.

+1 also

As one of the contributi= ng volunteers on PSL I can say this is important to us as well - that these= policies be defined by the registry for 'top down' TLDs that come = from IANA delegation (we follow ICP-3 - one authoritative root).=C2=A0 Some= of the biggest challenges that the volunteers have are A] multiple, confli= cting requests from the same registry, B] ensuring requests are from the au= thorized source, and C] if a request comes from a third party - validating = the request with the authorized source.=C2=A0 Having this done in the DNS z= one would eliminate all three issues for us within the IANA chain.

T= hat said, we also recommend any solution be designed to not discriminate, n= or have any opinion on innovation below that, such as done by Amazon, Micro= soft, Google, Github, Centralnic, Dyn or the many others who subdomain or w= hat they do - and encourage that if there is a top-down solution that it no= t introduce burdens, walls. fees or gates where such innovation might requi= re blessing of the parent in some form.

We record changes the balanc= e between these by maintaining two sections within PSL, "Public" = and "Private", respectively, as described above.

-Jothan
--001a1135a35afccc3005304ee925-- From nobody Tue Apr 12 15:16: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 6D0EA12DADE for ; Tue, 12 Apr 2016 15:16:39 -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, FREEMAIL_FROM=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 FYVv21H1dihg for ; Tue, 12 Apr 2016 15:16:37 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A979F12D9D1 for ; Tue, 12 Apr 2016 15:16:37 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id kb1so118706371igb.0 for ; Tue, 12 Apr 2016 15:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=t8bPkFl+wxOryqCaklyHy6VilBGJ1rXfWpED774pT6E=; b=cin0oWICxsOQWObf7X4yGkb4hb/N5zhA1eyayxKFEYjWCx5Lu7WzqBOHKQOG8w7rWT i+QUqbpPKQVQECKVqJ1q0qmt/MU9t+Q1n+W/092XprA9hh0QuWIsSLxsn0LThLZeXqaN NWE0Z9l/8UWsAayipuZpuUeVWfI6rk5JtFDm6aKLoN0lgT6XHJ3t6MFPB0vH8vsVve34 tZtxX+kn3T/pznsB3eR0bVUiN1fWzMlhyCxe0itVLwZpnlJ2wM++Eb53sbquldor7IzF 8sw4+OCs2FiadK8YWpUQxfMP2CleCfUZcEnbr3WQ4FADFaeDL52Vnddpyna8Ju3jWOGX kX0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=t8bPkFl+wxOryqCaklyHy6VilBGJ1rXfWpED774pT6E=; b=IWCfF6h2MJKUSvE0t/Q8P2SU/VXQuku5qAkWEZKxpOqOSJ39bVOHOM1l27WlDTcSju 9wiVJtQEomvIILxBlsKa0/CJt7Oh+MjfTQ31udA8vuZYHYS5qW4KxtrAWFfIqj4Kjd1e TktYEd6Abwtc63xpjVyfmPMWBFeIJqczIvqJiYEwtt79izf8irzvyzzVmC3BksmP9sl6 sTi2lVvOLtPCk/q6ghB3/BfO7z/3Ci9mdsah2c5xJ/2tMA6FjAzy3YOpGYZN8FoVIJDT 9mA0/5pxfSXpIYbcmjTPxR0lmeh+SSeDWUfRdAa9yoA3kieCEAYa4LYVg3RtZJhnJO+0 fnoQ== X-Gm-Message-State: AD7BkJJLsi0IIPvFMTomI/OI+iAj1aGH/PEY1naHaxAddgrYGQiqRxogCs0ZeD6unuhY6xUMWlYg//mBax4rpQ== MIME-Version: 1.0 X-Received: by 10.50.83.40 with SMTP id n8mr26460388igy.23.1460499396808; Tue, 12 Apr 2016 15:16:36 -0700 (PDT) Received: by 10.36.193.133 with HTTP; Tue, 12 Apr 2016 15:16:36 -0700 (PDT) In-Reply-To: References: <570B5E12.6030909@it.aoyama.ac.jp> <8B580AD0-E10D-42C5-8806-AFA5291FD29D@vpnc.org> Date: Tue, 12 Apr 2016 18:16:36 -0400 Message-ID: From: Jeffrey Walton To: Jothan Frakes Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Hoffman , "dbound@ietf.org" Subject: Re: [dbound] Requirements for administrative boundary data sources? X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:16:39 -0000 On Tue, Apr 12, 2016 at 3:45 PM, Jothan Frakes wrote: >> >> As Martin points out, the most logical way for the owner of zone to say >> the zone's policy is in that zone or a child of the zone. To me, that's the >> most important part of the DBOUND work. >> > +1 also > > As one of the contributing volunteers on PSL I can say this is important to > us as well - that these policies be defined by the registry for 'top down' > TLDs that come from IANA delegation (we follow ICP-3 - one authoritative > root). Some of the biggest challenges that the volunteers have are A] > multiple, conflicting requests from the same registry, B] ensuring requests > are from the authorized source, and C] if a request comes from a third party > - validating the request with the authorized source. Having this done in > the DNS zone would eliminate all three issues for us within the IANA chain. > > That said, we also recommend any solution be designed to not discriminate, > nor have any opinion on innovation below that, such as done by Amazon, > Microsoft, Google, Github, Centralnic, Dyn or the many others who subdomain > or what they do - and encourage that if there is a top-down solution that it > not introduce burdens, walls. fees or gates where such innovation might > require blessing of the parent in some form. > > We record changes the balance between these by maintaining two sections > within PSL, "Public" and "Private", respectively, as described above. Thanks. Forgive my ignorance, but has a centralized vs decentralized model been decided upon? Jeff From nobody Tue Apr 12 16:43: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 3473712DA50 for ; Tue, 12 Apr 2016 16:43:29 -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 Jmi5F46b8b50 for ; Tue, 12 Apr 2016 16:43:28 -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 0771D12D9F0 for ; Tue, 12 Apr 2016 16:43:27 -0700 (PDT) Received: (qmail 71319 invoked from network); 12 Apr 2016 23:43:26 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Apr 2016 23:43:26 -0000 Date: 12 Apr 2016 23:43:04 -0000 Message-ID: <20160412234304.1032.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: noloader@gmail.com Subject: Re: [dbound] Requirements for administrative boundary data sources? 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, 12 Apr 2016 23:43:29 -0000 >Forgive my ignorance, but has a centralized vs decentralized model >been decided upon? No. When you read the drafts, you should have noticed the part in mine that said it'd work either for each domain publishing it's own info, or for it all to be published under one domain name. R's, John From nobody Fri Apr 15 18:56: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 D3C7A12D9B3 for ; Fri, 15 Apr 2016 18:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 tSuXaMny4dIx for ; Fri, 15 Apr 2016 18:56:03 -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 7564E12D94E for ; Fri, 15 Apr 2016 18:56:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id D6F1610B4A for ; Sat, 16 Apr 2016 01:56:02 +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 ipVxo4IQFIpE for ; Sat, 16 Apr 2016 01:56:02 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:5301:b80d:5bfb:7c5a:fa73]) by mx2.yitter.info (Postfix) with ESMTPSA id 1AD1E106CC for ; Sat, 16 Apr 2016 01:56:02 +0000 (UTC) Date: Fri, 15 Apr 2016 21:56:00 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20160416015600.GE475@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] Requirements for administrative boundary data sources? 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, 16 Apr 2016 01:56:04 -0000 Hi, On Sun, Apr 10, 2016 at 01:31:11PM -0400, Jeffrey Walton wrote: > What are the requirements for the data source? I.e., does it have to > come from DNS? As others have pointed out, this has two meanings: mechanical "data source" (i.e. DNS vs. some other way) and organizational "data source" (i.e. who gets to assert the thing). In terms of assurances that you have the answer that's actually as authoritative as the DNS data generally, I think that the whole thing ought to be anchored in the DNS, just because this is all an attempt to link names in the DNS [1] with extra-DNS policies. But there's no reason that the data itself then needs to be there, though. One (I think unpublished) version of this idea early was to use a URI RRTYPE to send people off to the policy document, which could say effectively anything. Many people reacted negatively because it was too complicated. Of course, that was maybe three years ago. Given that we've failed so far, maybe it doesn't look so complicated now. [1] There is the possibility, of course, that this is all about domain names that are _not_ in the DNS too. See the recent arcing BoF. In that case, we should think differently. On Tue, Apr 12, 2016 at 06:16:36PM -0400, Jeffrey Walton wrote: > Forgive my ignorance, but has a centralized vs decentralized model > been decided upon? AFAICT, nobody's decided on anything, but I believe that the centralised model is part of the problem. We didn't get the massive success of the DNS through centralisation. A -- Andrew Sullivan ajs@anvilwalrusden.com