From nobody Tue Nov  4 06:09:40 2014
Return-Path: <suzworldwide@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9371A702A for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 06:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZs8cVGcHW9V for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 06:09:37 -0800 (PST)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234371A6F8F for <dbound@ietf.org>; Tue,  4 Nov 2014 06:09:37 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id m20so10735699qcx.41 for <dbound@ietf.org>; Tue, 04 Nov 2014 06:09:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LF/dBeZGvCwGHHHFCvBqNhWOHEb9wyUBPAnw7dL4MP4=; b=q224kmu7yzNvI8Ig6MHIZsVrtwsUCdOLwczfHMrnSRxFyuuVpHcbc4Vrz/PAZDeVNx wnj34LxDGMQZM6wXyFse34OxE/DaCMrRJ65gQvItXJDhF/R1TxoaUAUPC5jwXDCyAPHq f5iOoAbR88uaX2436DqVLjoNpHQDjLTR578jv8fnGFh8x8XZ0iEKKIionZch9vOOIOro uQ0cgPELtYP7zFDErobnzr9JSo96obMIaLboCKqIkWKUs0YbINKOHmi/V7wFtVur4feO kUfeKBCtOU06w1AERRRIPBri9GEnEN5lxV9oKr9BmOSrLomHjkfc6hQMEhJ1VMDXqg4m ZdsQ==
X-Received: by 10.224.74.194 with SMTP id v2mr67967271qaj.60.1415110176049; Tue, 04 Nov 2014 06:09:36 -0800 (PST)
Received: from ?IPv6:2601:6:3a80:77e:b1b3:de12:91da:884b? ([2601:6:3a80:77e:b1b3:de12:91da:884b]) by mx.google.com with ESMTPSA id f65sm452208qga.9.2014.11.04.06.09.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 06:09:35 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <alpine.BSF.2.11.1408230043490.25137@joyce.lan>
Date: Tue, 4 Nov 2014 09:09:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6DHw2mNsmZ0iUb6KPy5B7_JNuRk
Cc: Jeffrey Walton <noloader@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 14:09:39 -0000

Reviewing assorted things for IETF 91=85.

Has there been progress on the problem statement we discussed in =
Toronto?

I may have more time now than I did then for this work, and would like =
to pitch in.


best,
Suzanne

On Aug 23, 2014, at 12:52 AM, John R Levine <johnl@taugh.com> wrote:

>> Would it be possible to offer a few use cases? It might help with
>> sorting out the different problems (and make sure the different
>> problems are properly represented). If a problem does not have a use
>> case, then it might not really be a problem ;)
>=20
> We have plenty of use cases, and most of the problems are from =
existing applications.  There's a list of 11 of them in Casey's notes =
that Andrew sent out at the end of July.


From nobody Tue Nov  4 06:20:47 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758561A8883 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 06:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuEdOdvEPqQc for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 06:20:41 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0D51A8790 for <dbound@ietf.org>; Tue,  4 Nov 2014 06:20:41 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id hn18so6652262igb.9 for <dbound@ietf.org>; Tue, 04 Nov 2014 06:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f1sDwKtDPfHLEc/Ir1O1bO1YUTZQWmDKuYnNtmp1IbM=; b=T8z0kY8UAAg7nzk3xC19ZcbD8CccZPNW2xnO1ESna94nq95QPnKWfZEp3REztZQ1Ug Fklq12mhUEAFGdh5TiXDqT0oSoMdC6pawhFytT4iJ4mQyscKsSkEtVahSR9j9iWXBYJQ oR9wn7Y4iXrkBbpD8VY4Ug++T8rERg7z6B+cI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f1sDwKtDPfHLEc/Ir1O1bO1YUTZQWmDKuYnNtmp1IbM=; b=QFKnc3G1x1uHStacX/C6Kaz3jyZFlhv50NjtNu+4sqTzcGim2TsIxRTEcBu7p0ys9E P9QfemDsZ0d3IEFoDi2gYfqzpj3pjUihbbAzMv5nGswT21QbrpBl4wlHXQsAjuOs7UqX NmAXZT7FGGQCuZyGyow1FiqiMdWbi+l+TGQQ6gY7AtSryHKMS+hKm7LXRQYMH4KGyzF1 JbEyC97jU8+7hyG0HAtps1LLMMGH9aH0qFeR/I7DG4RUkK40Ir9i27Fm719UF448kHyB itrHfuKx+SRJ1F8Y2MipQorj19CM14X7OKgU7dUb582GGAws5mZaBlSoq9cIelIQ351i nPpw==
X-Gm-Message-State: ALoCoQk/cc52ZNbo4xpn3MtG5Yp3rXPZ6I7ITRbWCIeaiz15iDBgxQiSMDXsHKvLahX+PvtHoUiz
MIME-Version: 1.0
X-Received: by 10.50.111.234 with SMTP id il10mr24165897igb.23.1415110840624;  Tue, 04 Nov 2014 06:20:40 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Tue, 4 Nov 2014 06:20:40 -0800 (PST)
In-Reply-To: <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan> <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com>
Date: Tue, 4 Nov 2014 09:20:40 -0500
Message-ID: <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41432af9772f0507092a76
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ZF1MdDk4sFfKLWpxRcINXXLBfWk
Cc: Jeffrey Walton <noloader@gmail.com>, John R Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 14:20:43 -0000

--047d7b41432af9772f0507092a76
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Suzanne,

On Tue, Nov 4, 2014 at 9:09 AM, Suzanne Woolf <suzworldwide@gmail.com>
wrote:

> Reviewing assorted things for IETF 91=E2=80=A6.
>
> Has there been progress on the problem statement we discussed in Toronto?



> I may have more time now than I did then for this work, and would like to
> pitch in.
>
>
Progress was slower than I had anticipated in the last message that I sent
on the subject.  But, I have a draft problem statement, which I'll send out
shortly in another email.  I'm hoping to organize a bar BoF to discuss,
revise, and refine the draft problem statement.

Casey

--047d7b41432af9772f0507092a76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Suzanne,<br><div><br>On Tue, Nov 4, 2014 at 9:09 AM, Su=
zanne Woolf <span dir=3D"ltr">&lt;<a href=3D"mailto:suzworldwide@gmail.com"=
 target=3D"_blank">suzworldwide@gmail.com</a>&gt;</span> wrote:<br><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Reviewing assorted things for IETF 91=E2=80=A6.<br>
<br>
Has there been progress on the problem statement we discussed in Toronto?</=
blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
I may have more time now than I did then for this work, and would like to p=
itch in.<br>
<br></blockquote><div><br>Progress
 was slower than I had anticipated in the last message that I sent on=20
the subject.=C2=A0 But, I have a draft problem statement, which I&#39;ll se=
nd out shortly in another email.=C2=A0 I&#39;m hoping to organize a bar BoF=
 to discuss, revise, and refine the draft problem statement.<br><br></div><=
div>Casey<br></div></div></div></div></div>

--047d7b41432af9772f0507092a76--


From nobody Tue Nov  4 07:42:32 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EC91A8A5A for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 07:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFQ-Wwukyk99 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 07:42:26 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5671A037F for <dbound@ietf.org>; Tue,  4 Nov 2014 07:42:25 -0800 (PST)
Received: by mail-ig0-f179.google.com with SMTP id r10so6812712igi.6 for <dbound@ietf.org>; Tue, 04 Nov 2014 07:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:date:message-id:subject:from:to:content-type; bh=5R2df3Ni1Pp0YdUOnaconSgOznwQpAPXAOzzuCmv7bo=; b=CsKXtiI199JfMuVDmlwjk1SmcTLwgZqZ+rPeKrYDWEVYNb7SfjU/MBNCgRLh6FADKY EXmNN69Zv7jtNnQAfjaeaV4YcrYFmrMGKFEwmstZgRdfR/G2qz1sQu5CRcY2jER5BBME 1cxMbWyqRIWTU5r1RzBI9xDP2FEN4u5MGpnOk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5R2df3Ni1Pp0YdUOnaconSgOznwQpAPXAOzzuCmv7bo=; b=co+Qy5zdNGlV5XAwsepF1eV67ZnCwKrmvNFo8mUyC8GMPL+giMWfQumJnp9ltPgUYm Sb73Lpec/s+TL55OOmyzaUkHjVejNNWgzdF1v9jgJKK4w8pcnApeb8tmXUSSV4U5VCmr D92Sxv08dqQ3qCk+5C+/Ag/1r/LIBQ0RRx3jdIVmVHI/ghkIyw7v6nHGJix9QGlQXFbg TAIS8vIzVYrmdE34DoqQCvZBfO7TPyPPl2Bt2f6kVIwi/j13gSTAU/5Ak5lYzUEZRxYS loc4GWbJUxzsp4DbDNT5KZCMaFJw1INzNkXD4zS/9Vpu7prQXwQFQ23rXJtL9F2B/wRR RalQ==
X-Gm-Message-State: ALoCoQlmU0HZwxWX5w6luox2TvsgYYhxTHfytbA5+2h//L0NVOSZv+y0LPLmVnoACXuF2Pgrab2w
MIME-Version: 1.0
X-Received: by 10.107.166.136 with SMTP id p130mr3457363ioe.73.1415115745152;  Tue, 04 Nov 2014 07:42:25 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Tue, 4 Nov 2014 07:42:23 -0800 (PST)
Date: Tue, 4 Nov 2014 10:42:23 -0500
Message-ID: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/mixed; boundary=001a1141f3924e910a05070a4f89
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/CyfkFAp7fcxRxGfj1PD2_p5COe4
Subject: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 15:42:27 -0000

--001a1141f3924e910a05070a4f89
Content-Type: multipart/alternative; boundary=001a1141f3924e910505070a4f87

--001a1141f3924e910505070a4f87
Content-Type: text/plain; charset=UTF-8

All,

Please find attached a draft DBOUND problem statement, resulting from the
action items taken at the bar BoF in Toronto on the same subject.  Please
take a read and comment on the document.  There is probably a better format
for this, but it's a start for now...

Also, if there's interest in a follow-up "bar BoF" (i.e., "unofficial"
meeting on the subject) in Honolulu, I'm happy to help organize one.  I am
proposing such a meeting during the Thurs morning session, with alternate
times being Wed afternoon II and Thurs afternoon III.  If there are enough
BoF-interested parties that can't make Thurs morning, we can have a doodle
poll to solidify a time.

In summary:
- Please read the draft problem statement (attached)
- Is there some interest in a DBOUND bar BoF?
- Are there Thurs morning conflicts with a DBOUND bar BoF?

Thanks,
Casey

--001a1141f3924e910505070a4f87
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>All,<br><br></div>Please find attached a dr=
aft DBOUND problem statement, resulting from the action items taken at the =
bar BoF in Toronto on the same subject.=C2=A0 Please take a read and commen=
t on the document.=C2=A0 There is probably a better format for this, but it=
&#39;s a start for now...<br><br></div>Also, if there&#39;s interest in a f=
ollow-up &quot;bar BoF&quot; (i.e., &quot;unofficial&quot; meeting on the s=
ubject) in Honolulu, I&#39;m happy to help organize one.=C2=A0 I am proposi=
ng such a meeting during the Thurs morning session, with alternate times be=
ing Wed afternoon II and Thurs afternoon III.=C2=A0 If there are enough BoF=
-interested parties that can&#39;t make Thurs morning, we can have a doodle=
 poll to solidify a time.<br><br></div><div>In summary:<br></div><div>- Ple=
ase read the draft problem statement (attached)<br></div><div>- Is there so=
me interest in a DBOUND bar BoF?<br></div><div>- Are there Thurs morning co=
nflicts with a DBOUND bar BoF?<br></div><div><div><div><div><div><br>Thanks=
,<br>Casey<br></div></div></div></div></div></div>

--001a1141f3924e910505070a4f87--
--001a1141f3924e910a05070a4f89
Content-Type: application/pdf; name="problem_statement-v3.pdf"
Content-Disposition: attachment; filename="problem_statement-v3.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i23evjui0

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nM1cSXMlxRG+Kwj/hnd8csxral+OLCZswkHYoDAH8EEjacQEGo1mgxG/3rlU
d2dVVz2JAcIEB5pWdlUuX65Vj1c7Nemdwn/Kvy9enHz8ddxdvzlRu+uTVyea/rgr/7p4sfv0DAjS
TsfJaO93Z89O+EO90w7euV0IfjLZ7s5enHy3//z0oKakvFdxf4XPRrlszP4jeg7K2P0tPsagvfP7
50SejdJufm+Md/vr04NVZgo+7s/xtUtGx+rLS6bIxu+/GSx4vfnS5GDlgjeCusMKrbiw4vZf4+sA
8pq8CGe0rZYpq1uf0v7tqZpU9DroVC3/si/SG3zGp5j2PwxkuqvpkTMLOv0UX3sTvdczZ9rGCByY
AHZLcf/zqfGTdzZWnEtaoaP/nn15ok2aNJj3YPSUtUu7s8vGvkKMF8y6zzlI/Y50KiTFrT7+GuCm
YRtgHwF28HYKwAnsneDzbHjvz0CdWiVjiw2tSTG5sljWORTZtQkBZLsH9ZgI21jmGoQ3KlckF4Pn
58yrT8qglFY7P4X9l7g/KC4FFr3sD6bSk0kg1i3umCal0v6f+FLZ6GqefiLdWJWyrja5XdYQ1EU1
ZpemHIJNqJoAmrFZ7w7WTynMVvkEP7c2B7d/Sjt4F3VRc3TW2khYNMnqGPavUY4YcvKsR+1yBEcj
BYDxU0GuScr5mQknmThobaZk7e6gQS8LNv5zmhxsbQ0vm3VCk7wm3SuvUnECBQKkkFmHhegdCqCt
A1QB006FSen9P0iqlAJqFnCcsw7AGcqXQRTUFXCZgTrOu9hoIitTg+0lwVtcNqL/lL/JLworEfBb
bQDvTQYz2qKdqDzCmsmNshDYblgkb8HnmfcIvJewVWhWhi6ZIDhbEaxcrU/VwkVxJhjvZ1ZidrOi
N4w/lx9L6Qor4AsLs7C/1IXQ2at3K3XFQU1PyxjNcPM6WgC93JODQ04xJKbGkFReY2jI6COIMwMJ
BXACyYXwdHEK7uvAs9nFSCt9tT5vjIBsALC83AM3OJigMV4CcGEVbzVv9IwYjA6Eq1AJYnoFH0RK
NxWmTFQLFiEPug4WCfFF9gh/qLm8HahWvL/G7d0UQYU/k8ljUFoqo4b3YvwuAckCycJTUgAIQgLA
pBDhFZkLJY3RQKxEZpKK2lRAl1aUVmi5R5aVdfuvKPYDSGOu6Bs0IFNBURIvTN8XAzpMmwN3f4Ef
2klBYvt+L0gk88xAMgbi67r696dFEckJAG0YXHCJW2avCVa4pVO+on7NyE15WnC78smYo78R4oIp
iNs6HAHqRsZHGUQHarhcw+Z0eggR1gStVnHz4LTDZDpASOs5SK0AziveSwxU2VQx8N1CUBt04Y1D
dojEvINEgYFmARzGAW2hIvQd75s1u+qo7AGgrbXfC5L8H78IXq9YLgM+NfIT5sYG4Rz3dyS50UFL
ud4UaaKuuH3GS0BWrXV3xH84OrZRARcPwQzBSXALUJs5vwKO2XdhVppWqgpJlZ7kegcCe4zRlvjI
C9dolXGul1kIordVCl8ceAM1Bvddn/oJqhxqtpjqjdrwKxGWUy/1cTwq2KJaB+pBk6CwiPmPrwJw
IwjW4yoACXQyf4oqAHnx0Bj9liqgl9vg9TWu7icwOWxEyDUWYrKbkbtGEU72CBdSTR6yM4RykRxS
pOlJ3hpBlgmDeHjXJX4iSNhpikxcVJh4NMT/VLmB+AOkeCjsJ+NtL86io8gVB8qpgq6FxANAGNZl
lSZXS/waBK2qodWfYHVnJh/DGPkoZIAypuvScjGphQ7UGINPOUZ7iuG4NIaOYZC3Gbud8Aj/f7pi
/kbux7yCPXyVk97w2tmPKrEGqEQcfL9VWYvhpMLsKUVzPtoK6C/5tYVQUlThrFt1UWfLVeVt2C97
1WH/stUSVbRba1Hkls/DCmUBfukqww7SsnXQ6WNXaRxoX0fobc2UXSpdpT7FdtOD5FzYKGiNEegW
lKHBHUkbxoPjlZIBE7ahFh3WUVB/AhNgqOAMULyjR69AjRfly4TuQqByOkGHyziIYMCAoWymLyyn
XUYVBYcsGz0lEOLsnydnf/1uf4ZiQ5rIkcc3PnooP9EYGNKgX0YnW15zcw7deUwLCc2GcEBgo8uY
vCiPwHo/nXo3Qb+CGWX5+2tWh4vFJywU9wTjhaLZzyQch2TUI1BDoY7yYdh1dnYar7IqYyEXFMal
sktxelzOOqsrkreFfRV4PlV2LF+CE0me5D6YWaHlg+xwIZYTxDdCLhIgQR7OUgmSp5JXswuS4k5Q
SPbK2mkpNso+kpXzPt8Ddd+26obC31dY4PWCsAbmKnJ37ydn8uzubBftXLWvsEVRXbTkY7gBAGxB
GD1LQaS5ZjX5UC3+Q21dZC/aanG5iIRvUQdEiiCNXsg9fMBRpoh4wFFf0JYl3dqSNIWTEsA8RlT5
+mosE5Ir6Oqo5oOIE0wqxsH5FjKGFN4vCtssWGQKySwyETquZ6vdbky5gcaGKT9h0SAsJykkvo9j
jRjZYo2sJfmWVpSf3tX0zkMlHCjPmQQe6FPj0QguC7UldGwJs9xY9bfFUrDa5zTG9I6mewurL7Ap
L424EFJyd1s0BQD66pTaJJcr75NrXPGGCSLZN6X7hn7Mzq5zv9FMgCQQelZCaGIex711XmYJTMPC
AHZy4Yky/TfCH3CWAOSgB2VKq0+MEMC9mT25i5lGoK5fQTllLUA268VOsSK+pyiBdckgCmHVYC22
aD1Xnx0APBdA6io0NtZp/MUn3PS8CtTw4eRS/FNAHdWWVB3XpRQ/DCQa8F6iMZduoM+YN0uTmm03
orZq3iIimIIHqJxzrDgqbVNwUM3FGeJHNll4lgBrao3WJhS4f2IshTiEIxRwgHWAo99/y8cbWbl5
f3IImQjk2ptMUMSpHKVTOnCiW0J4Edtos+S/5OIDtQOoaVEAMGDJqyKUnTpW0slaiZpRD1UxSmeB
WSiyJGix3A9+avG7zfQzxG0Ik1X+WAEoswZtCfw9Xaqze97RQ3f49zVAioqTHxXWPv/i/XBi99lK
UBTmq9D8I/OjctIVoEdZcdada4WF4ASAdQVF0HkS4FFqa0YljFDR5cCVj0cHysjkHsBTWA8OeGFA
Sa5QKJ9Jn4lGZrJketAmWS5+e7zYouwiM9CBKxOrYmY3KGxzQaTy1rn72sJgGyN4TtUDfFiwfaCG
XbxGmlt+elfT2wgtaA5tlQ/6nFRMncqLo1wht2vZuInHMp51ktNcttJOqc1NC7s3FYgQtdAuiiJH
fPZULCw/w02SmlLlGNsYFGigh0mbAyBaTPu2wSM72nGi2hazsvVr9XJeWgnIUN73ksXAh8hsOecK
/zKwC9Dz1tCzuaEZrou0UY+85ZINpRdDEYX0xI2vFKGqlDEKvn1NSR3/wl9mlzr+QQlm6x+Ug6Rx
nnBHitdBHpOR6+LCRDPZ7Kt9sCuMdkJ/q9sifOuUGcLkYrhNr1gb9TmNDYnDRmS5YttTEo+dBh9X
GXr+R+J9sxEuaP7wepJnbQEHQbPHPLKHwvDtsvmNPRRliWJiS8P8xtWol346qLJYXOpAJHl/EdEZ
lbEfi135lDTUo5u4DSCbunGmoYtFjqd7ddb79jQZZJPbu0DTyUHXc73Znmo87CGDoT6u1E2G8jy+
NE3C+4DxCon1TiBA+txIDde8vXrUeK2T4TYLDmZj4rXQzj3q1EM4o8F8BmNX0U7mliPsoQABzPhz
f7xZj86oxHR0ScEFO+ka+0UXl4PPRwl1VKEV54XclbKenfdHYSKZcjjbW+2KIFQq3xY2F1D3MtX8
zD6TobO0ufaZQQeyjdCUcK4GwKlq56r0VJZuzGyHmrR0Z6gpW/jfd6hpFbZO6UhhYpWeUoy/Gi90
l1G5TgBq2uOlZ25yF6mplwD/z7M25Autuh3dM4tcs4FnWHna082Wo8zdD/0yaTTtOCpbx7kanRMF
mW6dVoohLmnwlZBL+uTx+e+M4oV8WhkvpR3LXlzKdhKC8XmKxj6qzLpl8hTMQ4GGgkgn0GyaH0z2
kJKUO8YA8Wix+wbcQ+5Z1yOFPT3upWTGi1O6oeaB/JtB1vmLSBLvma3oPN43VXjOFptGXgJG8v6E
y5d8dGCFi6MBBoc6kvNBeVAXH8SsqVE8SGjSEo8LUqi44NqOiYdnfsrr8Ow1M2J1jUrhCVth6LWE
+bLhEPGyZVwiVkcUWu5lP/lsmqAiSV06dZq2UZseNY8kACiU00fgF2OFbTuBOYwLKJN1JZK0IE5Y
XJpsmMdDkAnmc0zjRjXkVmsP9eIL/zieTBlaU73/gk6dHZQdw0LqEfMBLp9cpEbPevwNQKrrGRTQ
dA+UHmxu6NN4fF4MRipjhAfOVEex5cg8GPf3dLOQ0w+eBzb9T2+O6TK19RKko57mkiVwserxpcvJ
ZzFW2I7P5nLvsIzSxm3rvFNJLSRXVaxtBvdY0MWjhqCR/3DQzL5gvR1W0e95PWP4sBxPSnw27SgI
j3qifUy0bQou+NDmujSRu18IRMpB2/GCb1PtNGmbr2+sP9oAHWAVXu5CaCL22rjyodMRJ9rzbY60
PzvNeDBlZ1757sV8g8OFcukTigOj3Hw/I/LdD7qT4XS5klS2uRHLyPfX4pk64ByV0qF3n0NDvEpx
EeKL0wTyxZw7CndKP6bs7xyTbyoQOXWqQuy6jNzpvhw2GT2C8qDSrRvT5bWsLgS1oLiaIeub8Af7
hfxB0Q8ESL++K37De2pVFzZSAvHl5hBpI25zVNot5tvBZjnEe0SXws0pCBqXyVLbsYBW8aq6DKfn
/TrkyKHcXEUwoo2SiD7MDBzQ6bKd71QtQYC+jxAcVRy/Bp/1uDv/kCpkCxZjqZmaPNUlZcuNV50S
EJVfOOUAmmcRQwracwGCPxUyFXWhSIEnBDZZvN46b+lzePyONjPkcBe8kIbn9wY81s+/eMoaZz9i
EbyyVmox0q7LkDq6d74wRmQf5xjxCZ3G5Wh0Ub+piKGfck5XbZ1VOef5J2QQDMGPiRHvbZpvCpb3
JI5xoAo9X5EwWnMAVMpFW1HLVVAeDbEgm54MUEZqCIgNKufA5Cx0T6RX2HkKxg0zCzeEIfn6alvT
jXUnZle8+jYN4u62OSpaHEymr1Icexy/j87tZC7tt99tab45gsJLPA4WGZaMco/uXa9SH+i6xN46
9+bIq2kNAUgAnihicN29z5WCLKtkzYRDwBDQjTvn3uUQU5x7o3mirgYK4ruCdlcFm4g/0vPNBRic
A0Gadz6Wxww4km+n9fFqJXi/vj1fH1+sBHfr25v17VV33YuV4CU9RmM1L4a/g+06esSexS9Ogu1F
9gDNjD+3pPJZ598wrPKgotS7Unb0Msjih71oA9EOQv1yh/DuFPbQOZYQaVWC/g+AAqE86OBKjNDW
GRlRyomC1kr3tGLpd6qDyAF5ARR0dEqCJCoM3PuxilPpmN4Wn6K9oIV9timdW5cZZdpL3g/nw+VM
QdMkA1fGw8tB79/27TrjLa7UTLjkpuUsOvMvhEur0JxuLA08niroPIXjXQtUy1My44awaCU7ZasS
tGZrCXlNxUoMNKvXDTsdfev6prCkxl+sZcgvTh+5OQ31/BSbEdRi7qO3taxjNhONnOocMw+IekFM
468m1t9WbULW+kiRo0QZEXtE9KLH8/WxjV68wiZ60aNYdxO91sWG0SsZcHKVB456LIprNUFCz/LX
jCVevl8fz5soyo936+PNKp9YYVofL9bHNiTTY08oHzHoahGSZe0LQRl/6pCb8dgYXKXT6oVSg1c/
U/p9Crc5tnbjKd5Xd4u2m1pI8087zvkRf5H6wXHTaYNFzGPyDZJC9Higv90MCB4zd37Dq8dl4FqL
enTCjyT+eOjfiCB5khXeAzciSWnlJ506u04XPf/gAJkKtrro0tw5Q1ZMc0u+pxJVV26jhm900azc
hEt42L1ErzYRoYfYnMcn/pWgc9nacou3N0HO6rZ0KR3BP0YjaBn75ZajAfNKUU6v8XBQTCX6d+Ma
84gJijhqPMYfmV4OA4ZZZiVZGPTHkAJqw/8RSn36wWfieeRf5Yr50pQDNCCu+GMZM9jfWlRW6cB4
+l8QzIgSiU1kqPtuPvylCfybdPCrEwo//n4J5TBLVznE+Ccp83NXUVjYqiZvUvexKQZEK0OPdyvB
TdsMiVZGFAP0ti0G6LHb70PgdMbU92O3B9EHhyfVwcsbTYNfbv3AxNsbQPzWPOaktqfECNE0rwOT
IxUVg2nTDwolPlRR8QofqsQPTsRV1DAQrq2pDnDkgPJtsYmrGpdn/NYY31PzfBOWPvSp3EPDyNcd
HMxcqCjfyolkc2963oMSivOTi5F/swko0WK+SKBBor+dnfwb/vkfseML6GVuZHN0cmVhbQplbmRv
YmoKNiAwIG9iago0NzYzCmVuZG9iagoyOSAwIG9iago8PC9MZW5ndGggMzAgMCBSL0ZpbHRlciAv
RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzVXUlvHUlyvguGfwPh06PRrM59mbk1xoZtjA17LMCHaR8k
ilT3QFtL6p7W/HpHRGZVRWZlFOs9UmMMeGCpmJVLZCxfLJn66UpN+krhT/19+/bZt3+IV68/PVNX
r5/99EzTH6/qr9u3V989hwbGXeUpBxPc1fP7Z+VLfaWtnWKIV1HFSVv409tnfzz9eg1d2+R8PE30
mEMypy/9W3r8y9qAvb1bH39dG7xY375d335Y377pe2D9RmP16RYfnYFZn96vDdbO/vf5v8FSdeJL
zXpKOSVY7vNXsLgfr2/UZK2PJp4+Xd+YnKeYXfP6XXntUz59xtfOq6zs6Qd89tEnGPKO3gcVVShj
tuS1Eajq9Dzmhkj0eLcuZkOkbl2VSPT4ZtgD6/d2fTxMpKimHO1CpFdsqdiHs6H0oJKPIUeaJb2s
dEs6JqQbfmUd7NR0feOsn6LPp+fQ1ihr4bOOhEhlBy3esdcv2uGSMepBcic/eefyPPu7lWF+XR9f
rI9v18cP6+OblZqsB8Z979fHj+vj6+VxRNgbk8Kkk7m60XrK3gyZ0ClYqss9E1ogT0q+IQ+jRNP8
AKPCpGkk691gg22ECXCaH9ni4NzkzN4W722b1ih78659HLLt+3VTPu9ysHETrF0/moORQvDZHk+W
Du5K2+D96fsTo/7336/0nFjf/zB38v11IZx3ZsgI3uztJjJFdL7OiUbhm3LL9ruS38O/sHNYV8gu
hqb3QhsNkriyR+Jv78tbP1OBXr4p07YGentTG2g/Ez1Z23R8Q62dVTHjzt1oWHzItohEULns2Jb3
aHG9TKQ8KeMG27NhYM76ZfnRWdiIb3DCBibkBkSkDl/hOGnSyo9kzKIAfSpNrE5AchMnH2D9fKv4
h28YG7ximwUU15MKHmjEJzsv02k+wbaxTXFS2Upd3BeSq2BSrwKwOa5A+PJV6duonk/qkIHPqZIV
RDJVATeNTGozmWhnmSz9Oa0V6lKcoNbGoA7GZ5Vi1IVXovU6VC4L3lV9nACgmNMv6yN7S0yYYHqm
ELj29p49vyXC+2BgE16w97RRxintUdNCj8pkQxusJ2OVTiNtk2CSyc0La+S/6EKfXDz9Hl9XM/E7
6s/lmBtmRGWwfIoaFVZhjT39a9nAmBdNhFJF4mOyBSURW4vyAvdHg1iZpvu6hbARCwO5GE8/M0bl
GoPvOG/DeIXt/hsc00wOiMjH7Fh56YQxS9PmG1RqFla9q/ZgIJAlPhPYXBS8pDU3YZ9r25B75Yqv
lQ5HRtlqSOr7Q2kRVeZv7ysZUii7AItsgaMgaRsauMkYc/rz2JbyxRSN40E//IAD2ikYcZSyvT4Z
YG9hSz9dI1+ZACpnFVZuFn/B8RyKJO+Za7Uvhf1iSqeXzAgwdcOsR2uvcCnOLVtB33Wqu+ycFQxX
EYo6+0YoeDeMbxvykdrQ5rgWp2cOL9CeGD8lu2NOHPhXikwVPAZ4fAxASVMGYmygQwSN5ve4G0fO
oRF4Aft9YDvEt5kTlA90V8ZPMTRS/jPr5iWbyzHhoOlmd0jk+Uy4KcNZadVorc91rn7o3dFc74pA
JNyoRSCYGubM3CEOmnTcACjwB6MVx2PdsSaFr+skClbSVkK3AnwfQajly2l9X623aqw38DSgtOe/
f/b8H/940tcL9qHvIkgZ4ErhtYE90x534vSfOKngMgDXwhAhgZTFwhD1+Q379Ef2fMtQwrfrSB/Y
px+pSVTK+vlTmxPihABmMkZfjL1OCSBnIa+O2tuKokB3Aqd8x5Tk+3UcPt135TmFWXbre967NBcE
KhUtk3i4bHywI1yhwfqnEGei/881ar5gi3GywALgDjI7vg/5fHYJW+OHCAx6PGehb0UrwBYadMou
X+2rJVgfOGDhkN+EI2elOySJb61yjdZ6cW0SboyD/aS3KictMvTreVHcPRoBUx39pM3iLHIAWvYc
nLCUgUU5wKxYtOJFr3wooRZqMHRJwSSFvDi4XDNudXAgrQurBSrx3eZrvS+vU9iHSkCCBHqzxWFo
wW2HfvgWfib7F20kW46bqd1BhVUGzFzp1aUk6yT3Y6zzJKet6ELlJp11pws7D81q3Erd4dShEX9P
zGWAKAxzISOC24JRjT0aa9JLzT4KcvliY6hIt/zYTITjBuiXnNMOYmpkNf91vE3o23WyJMnuoic/
le8CkO8lcZezBQeqPHljJQO9E5zC7jKoznMZd/OeyDDgJBK938JABoNKyLBk573DiErrpT442ZmP
/7y6e3xWPN7C4zAI9LUHwL40J7PAB50J62zjVm1VBpe0mIhuSHy3EmI1OVyM6nobqCyAwoH/RpPh
hH61T6ReHljzkWp2sBgWOq+qOeccinkFjKlimLUwGHDNQwIvWHMebrh7SFFnHeYhKXSNKNNXp927
kI/DrMUgajuVmMK5QqXBOYmPNIOgwrQJM5Cn1xIa5yqRr+G2dmP1wLGhXl5VZWVdMxCTjtaL9BT0
NAOVOOv+MqA9bisr28MsEC+2O0PaPXhSShiJsnrEwyQjA+eHgD4PdH5ZV05yFKH7pHQrRy+r4Svx
YYBzgDXPR2yznpZFyOk4gXLpMR2NaGOHrJwGJNJt0gXcgN0EZ3a4AYdPzj8VN/DwCAgyGH8jWTG+
sZU3Qmj1kRTo4mL0y2JuBpEOavEFIbk3nvIfUaGptqd/vk7AAzE1uvNjoQewYNPZr0yCm8h1CcIk
kNvUaL/WDydW7CyKc+gl9OzP4i1kngHPfSmbGGETS5hSZfDQapjSAL8zhdeFzOexa7SlTLON4Ev6
6FYgJQ9HcSMi67U9TO8Asnq/oO3baw9eD8x/DgKTTahBYADvQ0OgMYYS5y6QsgCE0ZsT4/BgXkAL
6MeK1kIfDAEDLzng3e+KiYtexR0w5cDMuKeQbTuZvCvawPbWPJVol/HME2SaP5XO0I0X1T/wPnyq
mxhjtak+z0If/Dwx4IFRopXBTfgDjCGFLD+SLN8EEKVgcmsgBvtEzw/sU437VgM50sFL5kq2yMiz
rbajjdrEx0YW+Wv4HUsTQsWB+OuAfv9ZIJXkIWywEeyL3pR8EN38oyV5hkxPwtjkiYKVZ/7pj9Vn
sdj5Qz7LZokISVuEs5VhsjCFNewyz5GjPrOGkPYVrBEfhcdUt25KWWKX5hLZ3rqJwn701phVbGHC
ZpQXp+eam/bezHrAxCy5MZwJ2UwejqNmZS6Lo9o1jvoHem1MJnCCA4LbqefQKXiLdhTpVFa72lwl
U9O7bkLI+TtsEbLPgcc8yUICriXUv3bHw5k8FHoknhn1OJ6JKRvbU5WUsjEE2qGBDlrk7lZp2QjO
ofc1kOU1Sg10pnOBANhZBljzNHIZ0TLvpOdnh24YfMRwWYhr3Qvsb8BgUpvPruFGnqqutscCt0Jj
wjc584T3aAsQweQ+rbeEE4EqsMBDQY95R5y8bNpSnYCeQHmFzhnX1YPsMosm8lAd0bxF3UBzjHyO
kmyLLxox07AGH1OjjiTXb2A1qgZEbeC1GbkCS9ITC+dC4PqNj8Of9wpiAqiIIAdk+KaVkVyOS6qP
kvubEg7Q3qYzHGNL+UNt3Sa1u5ozTJSgBhSIv4WnpEvanNpGpSLTgLLz2YArKztROLbuPGDRiTqa
wyzhFkq7BywcOywBlDFKzUhcUbyetccPJWfuXKlI8JNJXZwUenqgxLRQ3TXRELnYiVqntGQvE+ru
NXtJti0MUVKVA54AAI5wuS8Pw7cqDrXFw3nMMp3WYzwj1lo1DJWMpjhQQTVIQg2A/jy48n6VGdab
EMbDqhalsG6pgXxcYfH9kJxVCbxSzXGaUvQ9m2PtX74obo5fRrGii+tRAedzDt4qgc2a+Z7zTz+0
7XFeIbklJub7AgJkOJvdbKi7eE2fpFCIS/oChxkMZ+fW8t/KJWmLBYIhLIBljssGPC5hJcHZ17WI
vItkPSyHvXGYV9dYh4NJDwvfqiRnCzsEBa1D0lLU8ScGrblZ5+O3n4I7BYyeKcOMj8DdH1ZeYIwm
CZTEo9U225IpxWmHRjPy/lobfDOX/uzb10skBE2Z0gDRda3e8wqs2ruy9ryzC7QGQxUiXCcJ9Plc
W/tWsqWqO4k73i25L2cz8yOJmjE29NlSlhf6LXktHwGuu1nogMat0OGkc3p6b3EbnayLEkvu74sr
nIyTeP2AzhRyWiWWgZXBVjZSOPpavPv4wcHJmxToqK3RW6yLLgXnclq8UEROGTHrMgfYbZSYtMtp
Le/n3Bq8/hf0dnJy5H6i1+e0ESzBL4vSFIAB0TxPRvfaA5eN1WJ9KSgG+YI+oI1qbaTD6kI/qo18
KcPMsstymVlXRYFTNbL4YGdOf61gS11gW1oh8y84lUmJ+akLGBijNzbsoDZs4UzrR3AvQIL7Xfx0
qPO5z9J7nTagcz5Ichfm/jv2fgv/SptXtaDGycHFpxKuedlPXc/n1jhUDRvZxWE8Ejei8NS74qNE
7QbBrPksyV4wi8r2eCSKjS8EpYrA1Vo9PhleQ1jbg/U+UpRHcweByf5srpeLfoZVFlIo90Pb3hrM
pcQ293wxzDYGrPgj6pMbDwBn1kKzLmBk9IQ+8rBIgoulICyCOUN7AOyOZmZHX4wAv5QkHlj7JXMB
i4y7uTOiacYsYsnx6imoJSLH5y14cAtFuPL/UvtNwzVufDPpANhU08dZn/4dX2cD6m6QPsaceF8B
Ma+ktRqXG4Xj4gGYU8509OLhMEk/CtYu1gygg9FifwLo2PaHjFryZHbv8Ea/sUP2hUnHLl3HTxPy
OU3bTzGmK4BBKcTKQVgfNNzI9usyTHYPVKJmKss5flaxOq4kJhgmV3aU4pKPIznQT8b2/tLow5+F
iQyC1H2ejLFMW+ePb7XeO1dQPgQas0KL/1grMf57HbAIWKWB6PvvHi2iaqJvCnTCara95BnW+yYp
JFYLSEyJgCJU200CEDhs067vRzqdVE/AYmt+gLhaKYI/NFgUk8KX4kz/RNbN+gnxjoT7NmNjhXwW
6UJr1aYLl+FXMW3PwWJndniYbWU13Ac9i1PKUwiLCyOfYJmncXbtaa+PJBx6M0/lZkakOKESMjE5
KCSoxUrguYazAr9yuiJELIOs4DBnkLYbfhzjMCIlWEthxQjsnP7GECmIjVoLlXZuWAh40ikcjCtR
6yCcfT8bjWGRWLBNQPu+jIEhsr92sJqUOHeHeREEBuXpAOEKopO9BEVTLOxdWWVOTvLWtyfiy35e
ciKeQx0DLlrOm7OBxms6+SocLWXWAqfuMp0vFEh7V0YJnWtdB9d6lHPc1Onv1KgYb6YwPnqyMLXD
pPUFiZLZgH9T2dC2qbUWEuB+G0eUIpKY/rwSrZfeUoOYbYM8F8ER658IVrcr/XYdoQJJd7jgqlAu
1+oz0BQANCxLiuzIWHegiIsJ41op/npEwqZSDAs2jRWeDvLDJEAt1prnXV2OsiypKqhLBiaFmyjV
hBistAQ00ArajXdYepFPf9oA6DkYhR/m3OYWumK+2bmUil/3sxWjOI+JwIVtVOi+LNGm0IkRyz0/
gJp5AdQOKnrotINJFnoZlMH8P+cgl/a/wVPa0KvqtUVJgyi8xmAWlq2FnPMdSG03TtoPQrrEXzqN
TokhbwvFKXWr01PlSmpOpKywkZt9iDdfebCeSVwaoAKNmjZcdiqAbekcm6Sct1Qmr/6ufKmzbDJa
DgJQNQ3d8blkAOQZS40fa5ciaPvdOhGcNjqFx8o1cNp4ncp5x0I5yK4KtU02luTX/jQDrUROFo0q
JLb1zYiYcjRrwf3aYLEqO+lCYiArGpiFnk2Lj+Ut5km2kHZuIduOMuEWZa1RU0YErsw7th5x4ba+
mopO+2w8OGTGyiHJDk/xS1yKLxefqpSCnEe5sPLuejlE/CSOcpP+Q49frvWCYX1OIokeWesFrq10
f5FoyweVXlUnFCFAHLnArM0RlfaeOgyiKPO176m7XR/fjzobeZRBTQkc2C7DOTw/CssDb8Jt7x9y
eA2ffrKDBy7S2apH3XVhXZrg/bFbCYAzXUgj2Z8D+Q84FsNL7oCjQ4qrlhQvZ6QtHXr7me7mHF02
tX9ZUD2TQAc3bKZKTyCqixsHEZceQ3zs2YeFJM2tVlQaAuy1AwUEP23ZFGm+jOvqpT65O+MztC1L
kSZjsw484QgYrLk4Clb8eqx6MgvqqqEubniZv9IwN5UDmDw813XeeSEMeG7OiZbShCc7zVVGSU9l
nrSnSn7xoiIaz/Yx6qGkDkUyggkyvlXDJIf9PaxFyx67h3Vzv+sll9WCGg5htRB7564dFRS0EkVu
X8snnyorObr1bq4iOf9iAfzQax4eY215ooQLGs+UbuoawYyYFDo0Nnbl5ytJrD2a5I5uwGFziAsD
99HunnqgsHuOQgXpMsfu6A9tylzlPJvGeo6TLozZzhn97iNzNnjFHN2BJoQyDMxDzCCfnymZx3sS
AIidBVjHI10wjDE8EBokj9sedcGQaCvYPtcFQycml9N+5xs2Ck1pLZ5ZJXAZURHOyqCNTNP3qneO
5gFer28FG8jt3V82rtswSm0y5irysUpkIX/fF9rjcTD/V/DBwKa0dfhTOdydnZedkVqR/5WcEQV7
rdoo+n1L8Y3hwjj+ah3uh1iS3ZjcXzY+NnLjy8ZLD8eM3Jl4Fi/OsN6wY/ZIC5v1Qf1g8daFdNEt
E8NjrHQa4BH5TloAerWd10TnH7LrelgkcCNeJkOz/ojMQIN0B7H2lHgtTXrJE/jGGLry/kV9HB1z
2dTaXHLMBauTVHOP1d8zMemqP3CqmNntotvQh/ft8DwR+al8mLW/OPdSBjZCCGx16NdOpfL6rRq9
JMiNVsVhHjaffRUsLiWs11p50NLsJhHSsGp4uHnNCXSZIGF7h//nAR7XTl/9Ev5LghseSIQXx60K
pzkvgC6gckm2awePpgVLAU0pYMRYqTkcCPYeltwh29LZsm2NYTzigaOcB3CSXMfX2C8ethxXvks9
SyzMLxfuk/8BPEIj+XBSgPDhfNU2z4UXd3T3p+HSPeBNOcRNdAjn37ZciNqnPcpbv0ienRL7fw3O
VSZEWgGTnZmmZV8umxKf0okrSz2QjWUu3AXxbzWfc57LrvTjPEEWCsfIxW6+pLiC4VxXMOQJ9vfq
hhJvc+jHNPHhf3r+7L/g5/8Aq9XLa2VuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKNTM1OQplbmRv
YmoKMzQgMCBvYmoKPDwvTGVuZ3RoIDM1IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt
CnicxV1bkx23cX7fqPIbTvnFZ1PcMe4X50m2LCuJkpIluvJg5YHeXZIKl7sUSUlWfn36gplpYIDZ
s+TKLpVKozkYoNHoy9eNBvb7g5r0QeE/5b+Xr89+83U8vHh3pg4vzr4/0/Tjofzn8vXhd0+hgVGH
POVggjs8fX7GX+qDtnaKIR6iipO28NPrs78cf39+oSajVHbh+BafbUhJH+/O1eS8td4d3+Fbl21M
aX72StvjxRX+T0jwk5HtX1ObpKw+PsNHnXLW+fgdPsfsjYrH2/MLn/2kVT5+Ta+NyTocr6ETa62J
4XjDrYOzdu4lhWyP7+k5am+XHm1O1fi3TFYKaqHX+GCPL/l90D7On1L3b8R7Mb//efrvwEmdKk56
PbmYgZtPr4B3RLvxxsFI1/SlT8Z7Jt7apGMC4uG1tdFlpt15lZVlAoDcaCLTzk2Idh99gikRLTGG
ZBLT7qN1wNTvRO9vxHto73Wc/PGv5xcmTT75maqgogowvIFfbXbHn87hdw2zqn6Xz7fcl9W6Iokp
he/kywuix3lvMjSAnqGFPf6Io8GTr/oFCdOTCrhMWyZBv2U+yc7rUp7LnEk0bsX7F0ynMccr8ZbJ
1CbnmTirYsYFvZhX8ELrCWSR1/E1tFcwFaOMXC+5Rs3CuAjdmFA1wdchT8F52clN3QJX1IEqAY3U
2gLTLgWDhCxIquTzVlxo+afzi+TdlLU/fn6eYHYxVd295QFVs9J/4y5UTlqSLQeUQiZXTYr8k/U9
K45xleJEO9nkZ8VBRdc2g2jD+MsjDq+dATNFw5e3b9bHm/VR9DCtj5drD3fr27Wznk4HA+Yvppm0
Z33uXq3r35ufQRsWHzi9aKDjN+vjzdrgen07rY936+Pb9fHF8njC9OS6SqV6sarMS9JcbaS9It2x
GqwKzJJ0J6jMPc7WJqI82JQmBRIo5O5N+d3oniVwMY5MpGx9hV2D8FoH4yF5qHw/83japuq7l0JV
C0nZuMqcDgS9tE45NoqDlHpgzYv17WKypGWQ5uD/BPn7ToCUaaDVoFdO+UmBLf+rGOgH0eT9zPY4
ZEM9PnIyZv0PniOKlIkGrPFiFn4QNlzaSikJ73i2lhzaZrbEkNLcwwcIRqh5alzIVsRHfqr1IDPN
lQe5JN8KEGLEdslBweHrDQNdjn5e6qhhBtKB/HyeDLhwAF/T+rZofThoB3QGg1pvzZQB9hyefnn2
9F/+cjQwHW08dHn8D0Y+RkckCixHcMagU7EAgixY8p+IJK2TJd9vPLSB7z6l1waodmyzAsygmK/g
VbRMqNMpzMwuz5fPiJnOpSIZxqcQ9dwGUB36KUKBCZHD7dr7Oxxf41oen1OLFIyxVeu3TKIHe/CZ
fP+aR7I+oDteCJCEzbNzmpGchbfK8ZpowLUzDC007k+DetxOI0RYTpJlDzLk0bour+WXbzatVfZh
XVqUNa/J1dgpKXxclhYo99q4xELhdAxgCnRZ8nT8gogFNAjK/ZThswVzXD1/BWoSA7RKJSDg5jAf
i0gilqmVcV7hc45K6VBN4lo8M5IGFUq+i6RBJ7OP8yyenmMQYi1Y3sZ8mwzdwAp9htwHpAF267+Q
VzlH8CjfcAPvdAvF8DWYj9mmSES9sSlXpRevh9BoZCikrZYeRlLDUNixh1y+rPUaCDDAXtOCTqIr
jiCiHP1/VztVuQdpeWQ3p0UjRFbIYBWWBZIWvTHBEMWRsu64Y2yC9v0LWkQIHsmPL3wuaCHY2LPH
6J9GK/G34lEUxbbFo7wvAgRG4+l5AgwKQEDY9mcr6pFRBS9kyGgBngu2NhThVBSow1ekMQ5wj5ed
iyiEaYYvF/jeDU5m4hvX0l36GxzfTgpW7NujYIngKysVeAQj9atQi6jp23Px4YQduinB+39jXVfO
sgjAojonvdlVHxkPRWNPvgDcpNoR3xUpcbHqfAk+GbJ5WKC4QhQ59C1PRadUSf+zXgfXzEftnBSy
BnGIqK0N7GjABo49EOBZZQDg6X2tARgP4LdYQQjkihUMCsLNb4qeptYKskZAlKkfhLGuyqJ7P6Nt
7dhGWRy8yBgNzYLlwVmWR0okCY0ogs00FMG2W8mW1lDOocSY2aUC2myqTQDiQQsypPysqiqYmdsE
pt5yC2u6lps4zF/a7JQdoGJJayNqy1K+wIHAOxu/BD2+JzJyktSJ7JwhHhqsBuIBugMupCb6+mL1
hULHa3UHYwQ2PD4ev6G/lPxpaRMC2qBcso9t45mXANcmr3xFHpoDANcpVBOoUyxIEiqFdMGDERv/
gV/6sEn2WA8LqXc9GTYJsSd2rfC85mGUr5I3z7kLULJXC6evK0lY3eJv1s9+PEeKbY6jLNMPLZke
4hVdpdOeFctgp5yWrIUMkIQbe8dkZsBSr7awouTbKOunXYEJZANuedIhZelmhckpeRQjYSFoDUTr
NrQuEIKAgGjuDp909rngUZUzOLpXqAQJPGdxAwZ4SXEgvjY+ECAEu2lSDj0wCqGPsmbJkYDiwVig
hP7434z5tcvV6kthuam1xzlwJtqPMnaNgGLrnH0jFos47aBO5zwGIw08IE0JqRLEV0KOtqq++Dhw
8YjvpVTVDpFmZmyrKQ9y/luRpeYNFsa54ZaBZFadyWZi4LH4JwAtP/MUtElbDCSM4uyfsIOk3NAH
Cg1g/A5B4KiB7OMJq1aC1bHLRsGDHSY4y0lF0xj7xzLgDuJCUOLh3OWqXmFzh5HXyN7ccIfpUYUR
KYwbWSNKYgfk9hYYuoimFeJlkO+JkJC8bQ1mF/gVDs4bYuCf4QuzY/tx+BBk3DQyIJw7whD2JX+m
XTe3NdOHTMAc8YnYmMzud0UqKckxSyUxNIBbqoy5+KrJjSJtKMIignnO5GTVTcG22TjGgoWIysL/
eYUxo1zjvpvFPPLrAgVBQHhnzoFp3YhWD8tLCRiAPvSkmFWDxy/xNXibSPuki5QP0Ekd2Ui6CZXC
2yp++/Mq2nJ7UY6JYZu1boratFkPfI35rNPC9S6fb5mwaMfp5GsGujHvyinSEnJ6PKOw+IJfc+cA
r6vXlwXV6MlrMwv5ohkFksdU70hOK3tYPBGBBluL5zg95VKY4N9KsAYR+0xAWL4LqXH8+JZ9MDz6
yefwcdyDeGEyaSMlOExMprIgcjPvE/H+dtDmikkMMQ9TbDtxElLg5TQ/ONDHKdp8UpzvUsRNyI1T
QVpi3jNgvMqged+upm+w4VwHRShS6MvBIfdgtrS7v1r6YAQAoBQUv0EAA7tSno02lUGUE+3sHtGz
/BRnquyErGvkUmnKoe15JWgCYvE4yg5KGRwEAoBRGIHbDFDt5UYUVzSsMGHHEoWEQLzzOJT8utEc
ZUC68ywIm2TYYPt+HPAuX/6KOwd9uGeR6Vk4qQcscokj2EoCkkquJ5TvmIcp19o8Z2ZTXT9wubr3
qpdPhGg3uaV1sWRYSGP6JN6W1BETWtnjrbU4geWLd4tgZKPumIzuhnAEJw1ArnLSojk6XSAxtqZ+
WdjCt5z0KA5szCp2531oU6L42lUR1G1pG3SdsZ0jons2N32uM5FNhEXjgWUtoYkJ9Zd3fSGdNc0O
y1pueAV0HWqOMson5GQlK6uMNqZWE0pPY7dY/tGirwUbZZ2HdURb0Sq4ujLm2ImLJ8LpeTJFzIme
OkHaOioIWY3ezRNz9sFIPC2h8JfYAixYihtIAK+9tqdsNI22ubZoYiNuLYDACYHIfhxapai/RYLt
LAQADAujmuTEc2ZD6w7e8xCYYe4yjb2OwwS9HkKqEXWjvcQRMyvt5tW2bUBGc0B/wTFfnNbKpBbX
lGTVg3HNSAFGaKZQ8XcGM3MiZC+TPruU37GaeOW5sMgDLl33I1NsTFg393K5DlkqNXIiKxQMVnPs
JuvntAVmwHU09+V6RAFeJRjatcke+GzCXfNhXo8SxHlQ6PmeKbJ5L/0j9rgwEWx0GJSYonfz2+Kd
u5kIe4q9n4FI03ezt00dBqraoBR/bh3SAxEhshGkuFEPdiXAeBV7FXY7ngK6W5k6bxITq2N316Gf
S6GiAT8MVmXW4DPOq0at25T1wpR+zS7m91yYgnbHJsUF3XkzNM2izGmL3NkqitWmpHueMrD1m612
0+w5UWYgWnxZ8t/GfXjgKP2Zc5F2YOviLZRln+b8b9mewXGTGhcHnzDVrdpyJRp1rZei7s38pdXb
2Uqkbtbd3fsdImVE2FcAkFVLfhBrD6OFNxKUV1b+qqyDbStUSLkwhSQ8iNw9ktow0PPiN5ii2nF0
lgnw/I/8FhRv2aIFFVoyGFRMh1u0CuasU2VSpA8pUuYo1WNVBI15eHoHLNwUshdmcJtt3NRTo3VU
mYgbwQJhg0fScF2muIG9lVzixIJyTSSzyEtTqT4nqDu74O22zmnlDzTPKh/6nMnGGoZTsvvY1oB3
fWh2f9n3dEuGsJPmX3wncGmN90iKJQv6xT5NbEJ9mFQ5Din+/0Tvk8XyjpNLUHkCldnfWhUsZpQT
QiRiE+6UDq3XCHbOMEi11uv+T5kWNIGSFin3CLcsHk1JHX1qhxQL/kyAFDVvzrRww4IiuvQ4bmJR
D3BWzjuyDIPU8CYvH6gu5B+lbhZhWdwyr+RHSCtok183WrHZe232DHGrAMtNt0Zx4yxkpmgg6E0R
3sy1Or7Bt07bkyqZ1r5Lcp/nWCmOdLeDvBrXXDhVsa2u2qEdCUB9o6LvK94zyY3nGSHYwY5UHZfO
csLBBhqT3Zohbe/bzUC3hbtKYwiJ1szlKjC7Z8t0kK8UhU8MkKQSj+sFySGbPApGBkfpik902W0U
E/pTO3BOqoH02/8sUP6oNkzCv2IFNbGF/LPaJM6Y+/Hx0mLYoTbuFBzQUQKxEDSdogRm3tcwwU5q
PQzZqgOMnewOcOSVjPdpA5kLyfkBdUUb8lw2hW2Ls0wQKKSTimq3tdIUzO8nT2c5sclOqZPLmpNI
cgls8njG4hfYG534aG0AloyOASKhulHcxzsGCDPHAwqjZPytLNhBNtg8zDrWZewUKOXhPogsl5NH
UjssTnqTYMNEMfBlx/Jh3W3Ubq6qBdZqveyfVLsDl1sppmeBYEvfdH6P+3Y51tCRdvmRquwr7DjS
9w1ILBRWcj+IzwdbIc0GAnAfsJTrxaf0fE98OqfInE5TdPokNzjQTWkWy7xjTvflNWpweMOU+EfC
hsgczB1WktApNGhZL+oP5kO066Gu5hAt6C04+dXgLkdL28OufIhUHIx9tj6un3VLITXWXS0bI+0J
AeAGud9P1xDtarAuDz8L0BPBTqaRoqZSJg1R+pOS8V6Th20Y0D1p3iGJOh6AVymsL8V7+embfnvW
RoBiwY8T4DWesiFMts63Sf405ZLY2vkwjMD2yznWUCl44OjH7sbYkPB0yS7mwNnZPD7MwJT44TC7
8aBkJ0oC53NsLOeai+dZXMW/opU1VN3RCe3Xnc5gehEbPUtvs2NL7isFsCFO1nf2y7abADMAy1OK
8qzTLyzRSKGvMF2tcbhuGJnVteFLY3EKinWi0F95qFFarpBCWbx5Sz33TmugCg32geTidA/QilOW
AGLyvYcs53O16fgH6lorb9189BSW2/HdJR6B/3Iolr4su+CwzPKkZCF2Pp66nIO9okePvJUt3vKO
c4ro4vD8Lkh32wAo0cmr5eRrwGqrT9au2R2YaPNMqzVzaAIU5eCqL+Ux0JXA0QnPFBcWfnouKzxx
dwbPpUkB326P06L1j6aP4rUX84GHcWCxn7RasvXYjU6xzv737IMkRZpaGdxuQdV9ca4ntLtz5KW7
AbfZbMOqgiQt7YdXKEkzJ6HeIKfVVrVgXSXI73/i6wyxox5vkA+uanhRrB5ErCHL0o2ygfnp6kRG
B/KkoRttw3SN6HYdhEk72eY+WZsUC8hzqSzgqHZ53WC43+jtqAfGBWhIxnkqbOGtP/5+BQIDIHLK
0adBFLiuT1MOYRJXuVRAWsRfRYBsAscqYOjXuILAG0G0BK9soWw4BIiI8SYaupQGKwXDwU5BpZyY
+xq/0SYok3tWDcsYwCocLqqPTqjYG1k6GUw1uw/ICd+UYd+VBVySkniieWAYpCJLZD4wRjPv+wmj
ef+ZxSd9XJmIQcRlPqhQCiYzJdfWxdYbSaY4xb0Dteh860q+UcGk/LIv5E2RKBYEGJUeL4+H87Gp
DQdwCoiG7p2lGTF0uAdRGd3lcacuFgcyWVd1sZx+StZvwfTG/fxWdIeVsDrQNUKjzfQtZ3tVZ0gU
nhE4rT59TmmmdQ/kBbNepd2KDGZy3DrZD6mboutZkgLylhiWMqAcstCG5ia0LERXTkQUhO5vzLVn
c0dopkUWGRY8MOzlywROKL694e/wtNDIupf5BwNiI+YgjT4lxrKfjA0jl7IQqKtikjohfxoKzLiF
cvyKvAs0efhxbugiTcoZkY7tx6wjJS01BJs07tzFK2YHyFLNVTlzWcT7OX6q4ZNykggYpV1V4vED
KwNeAaBMHV7yHRYdGEVS+veBUaX0iamr/UBdp4GBP4CT4cGBe8wi9YJ1SXRJkMcrkJwFuVNZ3kYj
NbaWWGzsXA1tPzwB29kDmQ/mwjiplqVGGZxFe5p7IkG3lnzOTXycy1/am6ykVpSECgRyr+ae6+Lx
ao9Unm3EtpSOfXTgAks1RRWpEtc6vLHo4WcXWOajvCxDHmK4LF1/JPRphDjKezGWY5k9WRgJ68Tu
MubFwtRuFh2hA7pD6Ehtx84aPJLu2q1meI01+5sbL43zCIR3QQg0McF8eJrdOMBT2ncY07nLhQYb
Hj4Q+ap96EXK2j+6MSrT3jnuhgswqOtsuSRQxN4auWk9/FjADG9LZbwIcAUw3TB0Y3nZqsuCikEq
fRa2FGd4p7XUgbbeopBTH2voWCEEEJ9zZljvn3CgHKPtJVofcgSIUq29I0BbiaIBayl6zpQavb+1
TpSmXx58Iy2BkzKdS2dOuQuMqHVUM/h4xQcB62E29RbAFLxC8CN8AMs53kQUe6nvBqguEo0b4w4v
Nap0rABLjZvxIn/E2QS8EI7zCbhpWySaBx5u5HQycyW9t5bGLxmKd3wC3/gqEJUpgUFx0tpb2bjf
VL0OFKHd0jVYpTFUG9m6qr4e7f7IRBNeF5DdI91GTfci7Ma6MkvQXiujMxjS9RQMJbqtSjFqVo+g
QPQXY2j9XNVe2tyJZ0qpw5NVmvWwnBnhG2bgbeqljRx+v0DpDz/sjNc1bA4ByqoavqvjpLtRe4yK
Du+vXhj14/lysY7kGck19BG9ni/cIRh5JdrI9oWvWiskgO7yMVXrHssurAJT0V60+lFmf/nySaki
VHp0QUd/A+J6vgTCjgDBdbmaoSkDaU5tUiFgqxp0pUJqYTy1VXoE7kdnyUYXYXVuoNDbt45Y80uc
ZdtUAs0lcci01sdavGBrHw2UOyYGp1FryZ/rdsR12ALmTCtOx4Z/eHr2pzO8s+vw05k6/PFMY4ly
iAedIRq0h9d4zwSe/ptf3Jx9M/xzDDYdPMYkPlV/jgFBHMi6phsMDP85Bko/g5MBQ8BK4dQh4l2r
mrYl8XaPlOzhwkxgE3SWgCopqh64LgeeIt3knWCh5vIzkwHHLM8eBfqN+PK3qAnR4WW/eN2YCQEL
PcUj3QycQsL0b+cZ/+QC1ZyYCEB2LlpK4DwTb4lalW0pCSw9kjF1YPs9IHbx6V3bxMAPfHEygHsP
hlGQtX7X/5MNwDMdDheOSio0c8wu8rKs9Z/O/h++/9DuZW5kc3RyZWFtCmVuZG9iagozNSAwIG9i
ago1Nzg5CmVuZG9iago0NSAwIG9iago8PC9MZW5ndGggNDYgMCBSL0ZpbHRlciAvRmxhdGVEZWNv
ZGU+PgpzdHJlYW0KeJy9PEtzFkeSd63Dv+HbuewnB2rX++HbeGa8j/DG7gyK2MN4D4AETAASWNgD
s39+M7OqurNejYSE4UDTX1VWVla+M6vfHcQiDwL/5n+fvTn59i/+8OLmxCzCHv5+Ig7/eiK19ovz
By9dXIQ5vDnRLsbFq/XN65PHMPLFybsTSdAO+Z9nbw7fnwNEGQ5xiU45czh/fpKWkgepAYjRBy/C
orU8nL85+evxT6dnYlFG6nC8OlV+Mcbb43t8aayIQh9/Pj2Ti3A2xuNHfG29iEH+7/l/nPzp/OTP
J0oEs4QIQA1MBlzXF9L5RUjC9W54KmkW42SN53/i2lE5LdXxMqEXlLXHJ6fwCAQzEfAn9GwI6vg3
fNbaeuWr9y/W4esOVnILY2FdTu78Zm8LyuyR2kW7RG/SFi5hbaCzsf74gR6jA4yebG/fbI9vtwGv
t7cbhI7+LioN9OEHIIxerP4M7MsBDLAnjFrsjQIaZuzpbYc9PW4QEPv29IFiUasACJxfwHL8AG9O
z+AJGF8D5O0sf0nP2mh5fMrev2ZTM5ggfTg+I7ZxwgvXHT6QTy4xsMMvb+5x+EEv8Fsi3zfbKS4t
SRhL0OOTbUDHEvTYEXXMEkHA3i1jCRcl4nsPmaz29HtcOwYTXaE50fl1Oi4rDJAcVIp10h5fToST
T7xgB8rUzuV2bijLWgOjS3O83iT/OQExwqmQWKs+GOcWHXXhrN+YkZmCqveE+wgifDmW9jEsRnKW
zm/uwdJeLsrFdPz/vDHk840419vb6wfi+buoQefdEjzneR/dYj5Hjlee55vudro9Ju7pdjrkNL7T
jdMShFtzmhNLsH6uMg1AlBV/ZQ7U1lRs9OupNYs1SnFu5U7A5R6fOQ+E5m5KefMZaka7RQp3cCYu
RoRE8vNTUDpaGY7cUyYoXIVcpn27eJTb4O9OzwxYcgd66g/wVgmto+f6I3s+Ts88H07aX2mwlq5S
TBdJ6Xmg4X8nl0o5eP2Y4fljknl0sGqVVuDdYnE+8QafvQfmCMB16xg8oLPgFx3Aep2puIQQZeKQ
PyJQ8JqiLP6UFcFnPR69kse/IDLegjf4B8RWglaNmT20lPwEBiqJnrkS77lJI+slyjvFN1lsfL1I
qzHVIoStNs41Jud0eFZhseCq8oPmM7kXeZGAS62qQ7hOr6PojNC65gCXVtIuEyWBwBVwbhFrQiXL
IKejMylCNDAEDayV/vj3U9ivBIlasZauHAbNWqmOWkfAGyXKwlJtbKaVX3cY4L+wQ+QoBRylRKyt
Gs1rd5ro9QuDwKFx9sg0tUBVBoX4Vws4DesPZxIIZ1VadIceKN+gAMpxGA26gBGVb7mMVnFAiS6Q
YK+32KHihgZ2I9etUnkEq4OJAjif3k4t4pmjnauXYS5AJYdfMYh8zE2CrrRuPKikIiUw0qoiZ05b
cussGJeXOA8srgpzsTXGYORWMSMXPq6/+SpPswjresMM+JPC0ly78LFcSX3MfAynBQyV+fg1Y3rO
js8ZTu8TbcCPyBQjtucM/j5RwQMV2IhC0xBHR91KALF9wY7Y3kmdkORMXbgguAEX2Gg6UwCm1h1I
iqxEUwsnF4C1Duc/npx/89ejotFWqjLTSO9AkDRQWSrgQjBhYB0cHLbOj0ZHRcbMQ3iIzIU+ivSy
qFQZHNiPn8kKwmiX1Z4ONrrsdxgACOT8agOdoAgX0RVEAhkN6qaaidoFvTupK+BpUSVcOL4jo+aF
ANH5ZYPN0SJaQqQAMCvg7P3I1ZIBQgjwBTPVHnes3AvjwBoYT+ga8FAiSBqHAkobZcory4KmV8k1
8LXdR24DP8l7jaeAZDM+oNkExgAP0gGn07QQW7nBacbH409Hxo8ci8ZdWWH/dJrXjFXMMZJLFEEu
jvs6qUviNJJcFmUjuMXno7lcXQ91EUdlhmLjYAHxF0GGu9hZlgQrDgctOQnLZi7T66SNrF6El0Ub
fcQFA2hhVXyu2usd+FykuS6YLmKWufHgcS9ejs6vscB5IowRqtrXV2y/z9jUbs00tdNuebeVUefK
jR/Ei7E9nif2zoBVF+1lI2zrXt+l0WCna9kcuNSEDKceeqeo4MHUPE1mHVTJx7QkrtP7lb2neHHb
XVj4H4ozLQkrVSd23ZGFgHPJYhw/cXD41jgqNXBw/RflO+dpGH9M/K7aZaIDcrZzsXGbEBRNtrZO
9I3Dgm+VRtkkUfJ6iRD5Z1F6OYbwP0QbHYU5/htFPU4Ye/wvHBwEIG+O/070MKh0HifcwNgOjoC4
nXu2Z2miFj4mbs8ITV1YRicOvuU7B64H4MhyXBkDE4FoP+MItwi1609qh8rE14r/9omBOFLRRa3g
8uCicW7oqeXWiMzXVgMtC2En5V60AtOi3/w9juNVQgFI1PvtzXzmdSYjr93BgcMARj8ZebuYIA96
cQKDZzoxcpAkBPMqjhwDAzPAWz6cVZPAkwJyL8GozE8Wk9eEqYbTNDMLwcWoETUkUoDjmbjnE0tc
zr7hqzvM1G4n2APeRAfrDboewoNLxb1i7lsPNA69fzsZ3ySczmRAmuvGMeb2kG8jp2hcnWjho9G0
K7WAA9lGQUouEHwOgpUeSGYndLqZoruznjVKww+NV8Y5fJlsk79/lOKsIGsDz2zBKlEDvU3PO0YJ
3GtQAw+Wqz5+y5TCyG7V+TbSQX6UTlpdGzhL3eR3PqmEyGoYEG6xhoN8PmqmKmw3akGnby9sB+Yx
MPWuVgbJ67SZW5lRhpBJ5cR8JDOUd1iZoasa76E/zyUA9Y/ApIHsjLcwVI3JwXogDsWxPu5bJJy3
Z/IBRAAserNXvHoIFoHYu3otAZkWk16MzAlngUlCdrUt6WBUinARHy9s66QACs7fCsvPNn8r3YBL
gSHgPGoBXoG9z0fjHbmXeARKTrM8TKe9XF2sYMxWSKv0DO5fxzhNqUyVMk5sTU9zRl2CcuaoMyhM
PkauGW5k6prNlfVKqSbNIoGWJoRsoERMMJMiMJJI2IocGY6rdA5S+iYDiQeFye5BeE7PP6aJ1v7G
EXnh1rbahOpBjNzUTV7Ru7KF84SM3JfhLM0tyEWHYOc0sW1eJG4CJftw0iSk/ZQiC12VeqSw+TqN
H1XrqcS9SeIUnLArEsfDDSYYBYtgmvRjUj51Ap6JxScCOxSunJX0WM2vxaW2VSX19OswYzWJyOGI
FLaYOFOiaoXJq/TShj2q4xB8/BIcpCJwUNADI5lkY8dIqmgoBdEYScLWutVI2pD2ADrDqyoZMUsY
NNREgHZeTlqB1x7RvCCSEBw5IKw+2obunW/Z5agWTDpBFGwk7xX5JbM2UNmt8fpgK8SujKH7GJWF
Fn2yquFoFT0R5KICTnQS3lciwtZkwLPlSFhXolA57q8SIEoz1UYYZcQMOHanSa0pYJytmUcKmzU6
H6rVxKtdzM9gfHXlrOfeE6xn/KaWYx1Sar16173TBlXKfUMOBOOlfQBzkLGOVBI9GxagU+ZeGQrN
kcZCmEF4j/NGfUrKYBS9avtvtj4Q1lTybGsUYQ0ob5qxaUBqNfGKUCuPwyyGXIJeo6Blk66tggSK
zTiFg0GHwVQBvg7Wek3MUlAqRqCXqAMCRD2qXIYBNsXMKVVkhM+hvpHeB78WhKImfsSqEsjj421w
AqFRr36NY5XVFlTRh1QOUkalUgUMFkEWcFuxx2rlijFRFoR3SAGI3IA3S30nt5xYqsuYgMKiKl6d
FHcyxyvQHTOHD8swAYgZqgQgZ8+LHnYbuTRijgBFLMEmKdnzTc2kR/jd4cGAC7Zo56Ypay7Lg132
dZRSCv6Y8MAj7WvpxaDRiGg/uymJK6yP6WhCvFWG/BOqzsbYSnuiapxKO5vJtnCdy8wSm8+yQH2i
GYKeZ+0XLzID+maTqVyoPbdWrxh2HF6bTcvYTeswE3JWGVysDkgbB2ddmJjqB6GWlVmCE31tqxbn
UmQKilAFN9XrTYyuLahxF9rI22Cv/P0MyIcEXLow5YKvmSf1gVnoNn2LHW3ksJY2ndou0O/eT5sk
kmNtgm+j51Gcmg8qaNM6q7Sb2Bax8Jxk1WK/msh/sPkzDzvXMlFxC7d1CKVzgX38gNIBxqcBkYQG
NPKKZdd6sQUWHwqetdT0WV9suBmQiMD1eYCEciUIAzoqOQtnOD+D2XQaeE5x5TtLruCRx4gmbtpJ
N8hxkGHBXKQEfx1M0ivGcFx7JbppWbmbmGoWALGtOOgY0KbuBrkwJIDzylsbP8cZi9RGXOUxdmQJ
h2OsxDsRBgRa1QAiqZo8+qAZs6RPECa2QZVEr87NZ21ZSBEb67ospGn+XlnIGeSsatKjhKRvku2F
F+ztWvOQy6Wa5YJndqRRBEZI0LY+8wc5B7OgioVjuYxP+fgm1bWXFrcp58h7TpmUDVQMvxrAnwE+
EgYgOuzxzYol2povJk5THWuQYgHz8CFBQweP8xPDb2LzG4fCWEMx/sBKuxBavU4kMXrPU7KWmH8W
JPJ1OKW4tZ0Zk5u055isbcGcM9+4gaYgbmt24mZv0jV+q8TGRXadIDS0ftSht5MBJry0axJguEtr
aseojvRrPUlywFDN3lJCqLISA6+Cnj+hCXP7JMBUi94iSdoFB5M0oYsQXu15FevcR5jJ0OTv8NfI
gAEmyylfsoPmxqRpiQKzuyi5GUQbZimfWcVvp8cKgdsZy00KEjOpmHZbbVhhghE8e3QqnlSmfuWQ
t/0Zds2pbR4T40VjZsFHtz5WfFXpXKFu5NVxojPDOqLnfgS3gbmN30uTyCfBifGD3GZpUUFmA3ZY
049BpzOVeMeCj+XV+FllfhJXcK8s1x3TriqpmbRQDzKtOVSuS26zcy3pMbqBIfsaJfbTy5qpZzqo
KukNU/e8Ca71rjVW4O9dJi85q3uGHLPLIeNS1cRnRedPKbp7mV0pvCrcFqIUsGBjhB/QVoGXtkBY
MpJLAjPJD3ByTJpDZ7cP29ImIGDdvY8V6AiS8ECpSKJJ51dwsrWNHQRmrXlPtObMfl+kJWN0TfAI
mwLD8NNPSZW5uDi1JhInziVXJzyYm2iwujqzjv5dwii41qSvE7twD9T+Zsf1bkceD7gy7uR81gpe
ebNoqVvGV17ivYXd+oxX2FFepdFn7UyPksVCvX3n7i9EBUPiJ/iI40cViAeomXmwaE1Jg7M0N6+3
Mak3CaSTcyLWh0X03Om2JnDSlbsrD3olOXVyY71ts+E8E4VnoN1+PZPYwX5ZiblJ6zjgAW7dxxM7
4UkbrMz5oOYtqGKkHRiEaAb8kmvAOCAI2woOvo5Aah6qJRjU7Nr0ORGQBygROYV98ffoPlXU6XmX
9tPU0Yk3DneruOtueWw2y6Fyvh1fUuVG4f8KhrNIbmZKuSi/z9RT9s6aKaUMDc6tpaa7ujC5MMXB
pcVtMKM8sYsmp6yJ6abmYnJ1ofdsM9a1/9Tk1Lyl9ApmQUHxYM58UvjdV7vkB49v1l2k+pdu1FF/
hH3XAheYmZu7ikDT9GQdJqrd8YdTiB+iD64J3HDnwskpTpMmhJmB4DKD6bPglkh2sKTRL9OS2u7V
GWA5PNndFCcBaasszNh/ogXidlfE8cC6iKO0Q2DucNAOwfLkO/0NuEUfuvwfbsu49g498ftTJgZN
0x4VVkGu5Dp67X5AJKd9cxhsKWDzYKYB1iTLdDU5PO6HMROycx1Bid1sdpt4xc7mJofTMo+MxBlN
eUlhmd3sshSi4uLeBwHWmH7JEHXcicSGqZ+ykDcje/xZnxUgojh7m+ozpxtXZe8L3XobD8C1a1V8
ih78IrRk/aWFgvvFyZK7oOJksN1uAA/Q5BWQusWIkoBON0lAQnTjmDajniQio9zG0qV9oP9kxcjT
z5+sUNvg77YBXcheBG8nYjcaLJTbi9hhhGnKg/9EQ4LwoQ79ZpeT6mI9chteFpmVJ6nQmHqhv2we
hoqpSC/zuXeSsG0NtCkYsdyy75S2qaSMIcmuI0+kB6Z321k+YtsN22t22jqh7OwDirDBL8p1Nw3x
tbfrnTngXr191KG7M6exWJiZSEi7NiOT2KxcVJWq3petqNv4cDksV9iYc7tu7LZxEe+g19/4eJ7e
hp2m+8YGoFlraqXM1AxuDXdYTbr3KHAH/pJ7CcyEbF05aO440y4BK7sBEemt8DsfXkgD9K0aMC5S
MgPve7bNqwBFNh10XyDTlPbYdsOSEoh1KFc126zg0l15I9fYwka8jsJap/GYIRQbhYvE0LNvCnH9
/6ywnLq7TaLjiLZqcOj20jZm59g77aW+/bZfHcCP/FBffqDgtLu2A3ip/U/MCPwG07CxXZiZRvqY
5jW9orwR9DbRKw//l3Rx3Tq/Z/AQVxlmDsvkGvRMgvcywVLQN4q+sDDgMvf+2CERRdkdK5hsgFmk
X+Wk7vECLjEpUmCFo+GR8UoqrexcSFc9An46qko4TRq58ycP4uB7Ap/+CplS2C+s8cNvXipQueub
va+Q6XDAT1wCKauv3eFFSghzlMS+gPyxQ7oHrIIONn9WxYgDdpQDN6SGDwkOmj6cKfwOkcyO4OPs
UlHWC9AH2cVW1tyMGoHDCysH8DtJIBxeOUnf3wLXwwVk60v63omBEMKuc21yAMjxl7b0Yycwz5CA
yjlTCJiXKhgAo/6eziBGV/ob0swZYtcbwIQLxN62rK+cwrBYRbA2iqoCuAq2lKVWnAwv78iF4NLy
UoBKzO03ecy32zrf500r/KbaNUJ3EAQje61QbpAwSDADrPTDafDgrwjfI5tgFF0fDTbaIN+JiG24
/7Jt4ibTHyTye0bD19sI9nhdEdlJQ+lqv7016a2gfCboZKmFbpAj5D1disLHqFRBzWm19pJ6TMQW
Cc1bCsEEfqAXnI34MaZ9AACbj4vq/rQPFy1mUPLUILVdP75lsT80olorzUsXnJc5t12xHxhDTvg0
7R9vaF2lqzZGVez1vNz/0VhUWl//ER+VsFYyCJlUYF/VkR0X48qrdPHDGv/wHP+PiZT9bcgiZbfS
571oRx8xxS/0SSTMsxl/Xl6hbgWvvdYbv8vXgKI+1ojgW6Gw5onTVvubp/Hnt2y/N99taH+7MQcT
yKxV6PVTNnPK3EzyUp+D59levsWlJRktwkG82CAzlNQ2WGyPcuN41e6EjaUBth1Ab3ULrB3A98/I
8nr4yLbEqX+2mfHcMZHog2LnfPSJTJU+KYyfp5o165mk7y1xU0QTyqV1Zg1uGBgurdejdS462bi1
BK5czXbMR18x0BeT4Qwi51o+BPwHvKeY7yD1qpuBuBgfXyaCl9Q/P2LJq8naXHOwmYxrX042xpmc
zbx5RVKFfwbDky66fLeN4Srt8oYfM5wySZ/04ANXH3C8A/l7gnXsxF7zmTdMJ3Ak+b6fXfZHTVbq
arNMGaiL8MtIadOYCk4voyS6N5dMNPu1EgU72czUq00id8sGh9FaxGo4l5ys4X2ozdHNpulyX3Lt
rqI5c4AT9sKuuUd9Bz/VhbGbqtER93HfgpCqeMtmfrftlKlo9sgHcxLxgxrL67Mbzjpfbx7Sh43o
nQ3pzNDYhmzzhh/+s3g5Hxu58cuD5UO6Zo3c1kDkzyf/DzyvditlbmRzdHJlYW0KZW5kb2JqCjQ2
IDAgb2JqCjU2NjkKZW5kb2JqCjUwIDAgb2JqCjw8L0xlbmd0aCA1MSAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nMVcyXIcxxG9Tyj8DRM+zTiEVu2LbrYseaMVFgmHD6IPBEFCCoEE
TEBc9PXOrKU7a2sMMKQUOqjZqKnKyvVlVlb/b8smvmX4X/r/81ebLx7b7cXNRk1Mb99t2PYvGy6l
nYzdWm78xNT21UY4pyav5zeXmycw8mLzvw0Ps23T/56/2v7pFGbkbusnb4RR29OXm7gU33LpJ6vk
1jI3Scm3p6823+++3QMt3lvBd8/gUcHayu9ewSNzTggmdi/2J/DeMMvMf0//vvn6dPPdRijNJyZg
KmWnQGF+wY2dGA8U3o86gRM4UVL3BNfWVgMpu+eBDu2E1rurhdTr/YlwMIbzLqUzM5nS8DfKzPRm
jVSh1hhpvJ68VZHUF8hI6ZS2u/fh0Rsg+tny9tXyeL0MuFzeLjM0fDZeyMkLymim5KTlEYwuqP8X
sk4oYZjZ/RyZLpXkuzMigEt8llJbYXc/xmfHrUuC6bMdCOeTd4Tt+c0RbHdygr9Fwl8u/LtauHq1
vJ1qBocB75e3jYjCgOvl7eXydk1EjgFHNBGR8Rx3cYyI6E6piN7sT2CE0d5nSQSpvN1rNWkhNLXl
22g3zDO5aiHGejcpTkWV3hwhKssnYXzcwFnN88DSX7qietmVZSPWSigPsLxlBiWAE61YjTWTs1Ss
1ptJrSvwHWKlXPnkYjVWTY5GkfzmCLFqN3ku1sT65jewQK3lJKmkjBVA5zGSohv9ZD5Sw2rSUgml
N0dISJlJG3V/wzvrWlAjzV/B8JSArRTi1MpPcl1v7xAn5conNzwl7FREvvjiCKFKNQlmI/nvFt6+
Wxj67h5CbRQgDDjKnJclglBbc+4qQHhsFUAyM4kioCqhJ3dUQKUc/OQKIBmsJqkGpDf33wAHOqyG
GbgAE0iI4HQP+EAKLSh1I28ElMLTZMBhiWX0l/sTBTAYsODuz8gCANeeU3hNMwGyCvVtr3FmiCjS
4uO8eBxtRJpCW+MTFbAVpnc3ONZaEH3hHtPiRszI3sRfycm6cnvzCnQqIpHdefyd58WWXqe3jBei
/IHMnMg03hVa8oR4/UdxFmV1seTrPRg5/N0Ucw/Ui/7wJi7JpQDwg0MUM7Ad8su4BS48SiUOtjIr
gUrcCH9OTHJAYNYBKQIfUUmFh81D/Gfb03PQIr78blrG4sATyUFtrdjCA5AJSDD84Jww6mBNCful
6gFrKbATbWAHwGAmJahHLQMwF8YweCyvB6wcrJ5GS612H3A+8B9eFQz+mcz9msiXqiQVJdX8Sqlg
9krVXsY9WKtWVQ2GONjPiqqhl1TW8d3naUbj12acKSf7p68pA64abiFv6WhckwMFzhYsv4lbFmDL
lJSrJDcuCk15QdL3y6iHxoBP41kPR4pCKSE6HpeE9yzxEEQrejwJLExc9kzl18E4fiTGcbHMTYdU
Nop+BvTW0ZWCreTdnHBIbw3zcVNn0Yc5S9ncUbnwTNnV6jBKBXRYCTB3KcjMlMJbdD9ago6/28Of
OST4xd9LVwWTQTwyrjCwB0BbnIbrooJETek8UQ1K2LFkfE3nizFXCbESc3E6iOkdV1TFmzlEVAEL
kQRXpogc14RksvTzAfvAgVmIxhyWftKoa9TzNqxR3lCZ14u+iRZiPWpnZSFBW6lb/5AEqXgx5DYJ
Rqji9flAuWPkEtz13F345Wd3m0U0hUR2MAUtIvEdFQvPd6hYeKZ8/KIo/dXKpKztADgQx4oyBVjE
/aqtBvkcbqu1TjeBXk9M1jQFiOPlwPTPCCF06gHMmBW/9B4ZqFXIcCbubYQvpgQ1dHQmHxBO5bHz
3KugCrdoMtZUEMViAdowpdGMIjBTFZCM0QJj44xaKlA5mxx10ddEX0nk6Bi0hn816AfSjkkAai/U
eAxWlMFiWR0hZ2LSM6wkC/1Pv5QzwMvAAZgDAM8Mg2his1xie3xPBE5BUeUAu7pE319ECiQfwgKq
FQPrGoOleR3qgX8Y0HVdjlcW/iXtbLDarcdAI1ZjoMV1/MNjSY+0EQ5JugyjEFcnXb5NrGaWqmkJ
3aIsbOH3qW9+3frmoNRkQvrTKnxk+qLeO8CxIiMZLiORB8SyFrVpr1wPSQsgiA4B3gsIVUbI3dNd
qz9BxaaBy6LvAakKZYDqkba9iAspZ2pDFQApmJAVholUmRGyGWEDqtQlNqauHSfnXld2j2+l16Ml
rxpLCx6gArt1AoC2+3SfNu+H+zmPfLAsVpKSoxuFG+oAq1ggAF/pGo4H1deYSmbNfxHX09YXLBuf
RIbRXhWu/WfyTKPkJSGbmkqLJoJ50CnbMB5+mdCE6iQi3XLQSdptEUFoUBgYVVH5ENpCWukbfdVu
AnWlNleqRvgdK1AldXH0eeDgO+GrV2LBhbjUwHvEDgpwzYdInleraW8gEDZzYNqLw623nR1HlIMr
6ib+RjbJQ+joRO6wXfpM4SD5aWXB8NYxUUi3qeNUZSv6fBIIUVqLOipFIMQnZyogdFeBLopjWA+g
pjKHuVEaQOpQNOpQbRnl2NeD8RX0+uIxN9tgM5BQn77E5Dru+QQr6My7uHUZfqUhwUkzKMBLECM5
bJJjqXj376BaArLgBDQUsypERaQDkx2HQAdnEcJk7Q+zJDrKaiziNAMkPdqc/uH73R/3c+8EapqX
EFeKAEIREn2m+K+Fd4thecDZpo4g8BqbReSoKlbC+TAEOFYaxqAYQZWQ0vth78SktY3VJzGxlUDw
IhEoV0unyCzLG5uLPBQ9ooKeNAzCMoCpPI/HYoQceqyY4igjR3FyNoDLuIKHlPis5TXa0BUCTNiS
ouFytDBZ4iZZsgQzd9mSM3MrWVEbox6F2ix1SzS/HyHEiyQkY3f/xNceSOGCWvYvZKVO3SGsSkHk
EhBTNSxurYh83yADOGCbcoON7gZIWJYokc1Y33gfNwHeLpUlxeScauuPptGukZ2lsofWw8SFUhKK
yA4g4RG1J5ovAOaffFkJSG8ZV8eW5XAapLREnfgW9vCxSnEUh8NuJ+PkKEluisewS9EA8fCa1Y4p
YkdITJQg4JE6AxS6A0TU1rZzOhV2LnQ+1ZtNvcmORuWyAepbsTJUFs27B00UqmOqlgBj3GJhN0cd
uEgOgdDykQRpQjaooZ21Whieq1wOD4ucqKsY+NZWngtjGJ78uKIo8NMgVo3yqqBvkBR7ngKxw8Sm
A3FXS2aDqNgeZI4CepgxBkhcH52S4E157DbxB1RhYHdLKBkF7ZEHu4lzCzmO98l+IDU2S9mBepRy
j0FofK2ejyOY9JWB5b2Qo5RnfbBITYaGmgMsbAA/+6acCnlx3+XRzLCgESqgACBSLdTaKl70HRoJ
XWmI5SyXrsNrtBEH6guyaX2U8jaU7nCEApUeALo5ppy3ZNCYnGBbmM4fpkYpEBp7aCDsahplz8Wy
4bWasPWA7c0wUlwssmlPOYuiby635EVLunB3vMpIG9QXlqH5V9ulkDuQo0UBPNRzLpbyduRJEvaD
wmyvrBC45MzInkY17Ui+8cqaTiFqDoyodNYnAdNybWXZyZziplOMSvVBSKkgswpo7KIfjN7OIqgr
sJxNxnc9Y78hRzG/gkgUxFzgyhGHg0APwsdDullmhYBwZCzsQx4Kf2ATMFGTAuFr3sCfk24KNOpj
uIxMMLqHhjIOxIWkG53/ExnOWx+5vk6u0D1OgAVNVSbO9fBQquqVNKpAF7ljR2ZwHkdYh6n/fK70
GEcIUBBIFVNRyYrl6IGcW0YyCvCVcksR6uQQDCYYdSQis27itj7jGlU8590jsnCg2aWvwuBvDUzT
roIwn9NDkoS7tDEj3HV3Fw0dTX1jpq7cS40akH1OrSgl7gVdyD2DwejguBjeCwAr6po97k8RBrgy
EGdlcOUxdHF+E1QbgKH1jhz1sNy1kkVnCnf8Mk7MpDpQhcMcvnbphcNONIzxDwEvxAeMcPJnZMN0
lgOSxPnwWzb6eujpcZEsn5cKds+KNk4oquoOPThHmhRvdBTfst5JzF2tWLh1KWRHY8qDejpd7gtU
TWMZvIWdH3Lc/pGqV3njP87VK/SSSbP7AGvQi0aBxoNO5iF0sqrB5OtoIly6XCXqpEEn8xn8SLlr
AIstPiAy0h2bKmYagzfJPB8jA6yGQPFV7JfTpteiGJEDPdGmiSRFFKNA0Of0USfwWCTgWnd8frIg
CZwWonT/5alkR5VC9UEC+5oSdpzOrIGcMEStZw44hItenTmggUdRDs511heBLKJ7KUX2HNKvWalH
wIuo8m1cRDKd4b9zhTOmc6TMQjIby6RYs1KqQhxV3aCrpRFLCxuFI/wk6hpifXIXnjMCUOXRNZ35
2ZKO0gLPuE4icc+sqfvAW2GKzrgkJoaKFkvBCqIb8kQKYINtCpVAKvackmahf+AUDnCD1Lu/BYo0
U7KoYdPkjXCkU7gaFeNoH7cZl4VpNtgaX9OWcx7lJL1ISczSs92UlugygwbB8TKxUgoyWXzzSiZE
sV5Q16qYiTSrUaFlBaij8KyzyR0wPHusehNnHEQOC1MNNBJfwpU1P6DAGLvdoPdB5UqgRR+IygG8
TpybURGJ+Ifi1GcJrdcUlo/wcrfCU8NUpETIxsN1Xjdsw3s6HxVOeVDrlrFg6foQQp4+XSj5Zu/w
mrAs+tkGQv2SLPh7yABBf1R1CJ1uPjiIRnzupyWaPGqKJYLEejNAHuzlj65HIRallkFRzWCSwfn7
eW0CidAiLpDy/MPa8NaK3BQajZKv63J8PJTvgYZEotB4b00Vej+6s0HnrmqYuI6pWiEGDY9lVa3X
yoqnxgao0Wr9mk1SsjAYz+A/Ri3xQDfc7d8wAg9MjmrFzAVLJuf+q4/XkxmVwa6UEHEERHEaEUZz
P99nlPJDEpcqO3tbt5tbuELflCtkPhctceOf9HpG2gNwvI2H4W6XHRsL5mqOlUY5K8ltujbHH95U
1HE3ge/TwndkFN74Us5Vxd3V7Cc0wKTsB5Kvr2I9mQt9H2P/TbMf1xx3VR3vMxcxskJgwhRuLXfB
0pE3qzEPZ7FHn/DjLK4kkU7zO8LE93G47WRD4bykDBMPOiUK0I56gHAChR2bmMflCOy1z/6nvqKF
hFg5bB879oqWd5NnbpxtHXlIdEBLZz4aAnduRa/HtymqkdLcYV3FOLcqF8d8DLwv3rp9ho8s3FMs
Oq0PP6byh1yGDs3GSAneLH7wQQxO4FR9YtCZILN0rbKMbOHrNmmwWOCHRkkU4TqVwLCr0naiae0Q
cObyCu8sk/KKbsrQsQZOBv/UBsputwnyQImiI5q0XKbOrEjz4dmV0OBj+L1jgFATK6+Vf7sUy57E
AVhfH0CaweeeyGiqVgjOIYHjjK9dJw47Wa3WIlHWFjkRBTqDE8qr/ujBGeY4i8c6CHDq09w2wMkF
COQgYwqcsoWu3cTXbEkKUn9UrJthV6jttWY9/F7heSTaMlXXDgJ9DXnlYV6iqHD2rVgDG0rnTCjv
g7+aRryzJtpL0Ajo+q1fS30etG0E3s+6Hzajo5dPZoQK4Baki/aHH5xAh2P4/Ob+3xyBGSamw5yo
fvGDE+f7+cMd5Mse5Hsfb5a3z/f0yx51JzVWlYAu1nofwjl6zlSfJCLP5WoXcj78+I1MOVwqbU5l
5yXvvoE/SAzX4W0+EZfYiSlVHSxW2DZjsPB5Dllf0UwZGy2v16cynBsUW2lxtABMnx/hXTk7ce5+
lYPILBYFyBwS0U5lOOx/dKOqL6FOoV4S0NTrXlTYaWNWG9yVdZNcrZfFEavfi8AhTDZIP/zSNg04
3cSfkljdRQTBYf/8iMSS/YHlwo4ulFHwQ6twpTxjl4jDQ6rsNAhN9Hc3cUVdHO7U9OMnJnWBnoj5
kNp0iiQSgIWsENMD7vlmzZ5jRg+vzo2AeNgqeA+MhucD783HskGvY+VQDA6OzPKDUMOM16o2XRqv
4tUehR8xEhgIJCB84/KNGpVu7uh0Kwygog/aB6rDDRcBH8PUkEYaGT9VZZQQiQMA771MPoQba4QO
H8qxEMmEAgvBt5rlI3OhnQl90agaSmVcCNYkrcyTGJAkToLDpc61xPT+9V5yvA4o6ITdaMfBMZq8
ybUr5DIbNR5j1/4S0wXTNowB6MdTpTWHAUN8v8GuTvIO+o4O1sGZkyPoXp44dutqZL7K/eMuQY5r
jWuYVlo5rAf/GhfjZfNdoiO+CJhuoRpxWAdk9IUAL1TvJKNuhjTx+1dn3bNpmihWfXTVoWPtRimw
aBtOu7f6TjLRpSMlCv8A/wZ2O3Hbq63f4+yPhmKcUPPmQrNyEDPqr0WFxMbzcX/NvGBsIlO87X2F
eVVVEn3IF3hgGlF179z9UbX5z5/vTzRkWswXyOgmzoupe/9LCtV1CGQdnpX0pxj5p3HVJG9qrKWx
pOjCN/3K1DMoIzoLZ7HGPkoVB3fYesYwowvYpXJVKYeW0E8yRWUN/SN1N2PRCJOj+14jp7KWxo3w
8uu4Anq3s+4RdSVGHOyFq77FEUqM1R25EUCgmnyR1XRwCj+qNp4nQnhzGSG8lutZeCr7HXIPfUpV
u91fl1pW7H1SXAys5O1cMh/cBg0S8eHyVOeDCQBf4Md9Tx9o8aap0+BRm1z/Glr6JSXpPRky4nS3
LyZ590hokf71WhZFL3Eqeh3lMJ1rOycDXk5eMty4oZN3PGY4nBt1NrXFdhrIumdkcxz7D94BA8ef
ig94MXX45UIC9XMjiDJr9eNwOLjeRJHKHQPc1Lm3m9oBFuXt5md1u4k0k5b8wM+DhORBDvtHZnPv
H6fOeRKv89hcIToiq1HA0OPO05cJjzpGjwcJkPP4XtfhlxWG4qBzHMuaArvTffokp54JmGuC323+
D8rLkzFlbmRzdHJlYW0KZW5kb2JqCjUxIDAgb2JqCjUxMTgKZW5kb2JqCjU1IDAgb2JqCjw8L0xl
bmd0aCA1NiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM0925Idt3HvG1X0C+fN
uynuCPdL3hzLSZxSJbHFqjzYeSB3SUolckmbukT5+nSjgZkGBj3nLEnZKalqh7OYRqPR925g/3xS
iz4p/K/+vHtz9cUf4unV+yt1enX15ytdfnmqP+7enP7pKQzw8ZSXHExwp6cvr+hLfdIuLVGHU1Rx
0RZ+9ebqj9ef36jFWRtd/u+n/waf6sQ/LY8pw+dP72Hwb29u1WKctun6xxvvFm/D9bMVwPVr/LW1
Ppp4/QM+++hTMnzI9/jaeZWVvX5xc2uNX0Lo3n7DPiwj7JJiwEcYElRU4frvaEiy1nbv79gzB/kt
4ZV0RLxNhPe2h/hAEK2zunv/Hp9jDMkkfEZ0VYzXb7cFvcS3bgneHq/CAZjUYfgDm/MvN7d6UcHn
zB97DBFvq8vKiCj5+j9pP0yAAV8zcF/REO/9QHvCw1+/u7k1afHJp24SNvfLQjOnYPv5ctmIN/BW
wfqMMo3CZec5LV81XDXMjgxmgl9yjI2hvunpXtBLtk5OG/YD2+wH9nxms60BpiHEtQFs+ad1V52N
CXG6bUjdar1kbwi1n+Bbo6zNsVudtMkDBax1SwImkz5FZrLATBs2hcf4ogj5YNpmDUKwbJBJcnuh
v22ie6vhyYS6qr+tuJsIhIYRB5IC27YoZf5/yDvia4F5enk30QG7+ONV+EV3EsKI0rMKoqedG0k1
ojpSlq+A06FMHpcEUITR9xU9kLN7gYE5GTheTPr58OcMDNdqVeSBc7S1jalk+US8le7ertSeate2
fcQzsalDpUHvfc145it81qCIbJManH0qNfBzUTlUqfHpA6TmSySS8T431vLZrWQ0sKyZynVgVc4o
1NWWWFCoKnWbVydKMK3EdRzKPUHJWh/oeVRhzuhunlUn0SSgk0A9Pmsvudw1HQiIChaNqw9BZXCA
b+fczFmVswX/9B0p26g7su7pxy2tCVFE5TNB9h69CmvDEgAI4/hmJsnhmxlJnM7DhOse6SQKx7NO
wMqG6KniGkezIdVEIkKdgXzH6Me2+O0NGCtnTQDVWwYAI652ECCaRvioYQ1MQhhTPi9b4MDu/Nyw
Pnav4LuYw5E/hArAxaSbBsDd+KXs5u/KFF45e4bJRr3P2ZMLJlDBgWtkPHddONdIplgCvhemMvw9
zeNC/+VbfG2BsEGS5XeM2K8ZuzOJuGMqin/6BIA7iAJSb6H/hyCqnPQ509is2rqMBjL3/hfXWRzh
PfOm5jfYlPfIxsXrOChLpE+yceLAlRFcJ0u04vO8qVpAL1qlxlZiOOAwLLGyXL+o+2fjoz3rW+JC
q2KueoBQKpogqEyYPZLNBB+y95Vhfd4F5P1kFm+CReLbgNxv/1aeFecD6xP4sjuj6e2CsvmLe1YX
mRfwvELahaveLMFNbcaqT2EIkvkovoQh4M7sJXzvmu/DR0BsoBA5ihpk1jV2H+NIxCnZUTHR67RG
tMnO3Cuc8I6ZTj6EO6Qk9Ub30ni/CQcJQUW0M4eSpr/MHeMqeFXwuxBPh1OZ0mtyVh1aS4hbAemU
NeHhyPho4yoAp2MAfaWBEhoURbr+TdlViP2LwttGPwB2OniI9wgLpyL8T/SpQO63IbRGsO3FwQOA
OriAnhyuBey/qk6ETT4H16AAh4czkwb4YmZkdQJYEVb51dXTf/gjrGKNz4nBHMZkD8y34KS8xPFj
rvixJ3fGhNqQ0HkZhTFEUKQ961FUbZT+iLB6L/5gvR8ICxPCKPyAhdayqb1EV0mxySsCbyDC4Z++
Pb+0D6ExmIejELeQOzgxSvqxqhwICzbHTQpPGB7c6y2incEDW8WBtEs1PWVduA1auSGopW1wndnl
k/+EQ3xR04LHtzPMdSWdTvqE9Ib4KWs5Lr0TKMdnHbYC/fpoju1Q9euFIJV7T/12oReHG7BP4rXg
lJmWFd4uNDCKKyBQnlmZpn/+AwcHA0DqNobksjWECCANMGnOCNuhYjemmtiUSpCESicBFNJ/2Std
8hTwEzz+yjneogn7vIxIqsW3dZoKOmgfCbQtyWaOCVpK8NxAt3J4322T/8BgvKPnFFRqSBkfavKE
AE4VtENimyZMhUAJ9sz6jlUmLt9uU3AVCiS8lzfuAT2/AOI+Nt8Cm7J+mfetxn8d6RdAb25MSL/w
afj7S3KWnRpXGcypH/UHzI52inkmfMTe5yivuafTQBvNfSSug0YN07ZX1DAfZTRXHScl1d/1lh2C
UWDLcP2nazaVkB+fyHh5DV485vtADzPUC2zwm6OWA65zbvuQUi7whmD0gV4fZ5FhgA0toehCvv53
9JYg7nK+88f/dFMHA0twGCvTNyRSvmA+Rox7NsnUWSGyuNQny9gARvoXtGs6ottJ1hcUlfdNYbwk
DFBfMLo+29neXX4PM9qOMvVcIDi7cw7jz5KnPojKCnOeIrug6FSNNC24E6HBQYNfqYR6AgNgUMeT
Dd3JT09kzno8lnA2ldTOP98kmD5utUbUJNJ331Q9YZNo+x9XKnysG6stCGiU8qwPRDELPufzrqaJ
CtwqIyWsJkLMDMIuHyPGhWVyOyoQnDwYPbjBGKb5GMzO1AAIHQUQQwERBxtwJ7+pCaKwgEfRBIiL
Ow6EBT2fh8W9t0rWzq06tnA6zw49Z4LHnS5JwqSM9S6Qrvj32aSDokUEdyNlKfW8tzQlJsS0TILx
wA01qzfwOxMDKWY88IwBJzsIKbqfPrk+iYg4JDHwknSbYJy524G+YjKLNuH6X4t9SK4E2ZsTDE9g
NcyMpcOUFEhNzHFls2BkLtReJqwwLVjBwmMIv7QrRxYFgl61Vk4GQQO1F/ME1FofqewluE/f0W4G
v+6m6ryuzy+wH4zW1SIQwqJTVdVGch0Pfsc4h4dYg5NkVVpgWjEb+fcM40lrym5HvidjYPMu7QkT
DcpqyLaXDobk+XdDsX2Uu7LvkuYZPL1i2mDnqmlLY9IR/WXAEbNT+AgRi2QY9uF2gcEpss8pNp1q
VYCgwI8mXWHmSiwVcslvhNJ6Z2hqvHFBt0jrs9FultdAsdamBPN8rVzdk+9hXCTrDxOv5qkw+nt6
m+dFuS2Ag5VoPWOsMgsj477KULCvQmFpEYKz8rDWCpE7Y8I9bYlr7Fz5mu1crQMGVemADQdDPf5N
UZYKIrVmOuNM8e5qTkdJMUQq+6NgEhAxYC/Ot2X1NolUA/jLEiZ3jSQd3/xcRofkbYcqbbvNrrNm
bJsEI8gn/N85j19YrwCdqpQexQeIk+1xngiG6KBF6/F+9ZZMWhtRVnbp+82YQv8LjQjJf4Cab7A5
yw+RR0Hba8mNWl0kRLp3kbjLzUroz3bKdefIPGcWopKrFOUnKkJpM+rZIaIu7tUQUaPjmZNcrp/z
E9evLJop+seXnoBLMo87nc47YsgU8fekOlA0heD1NU0fot3ZEw/+pOv2QTKaKxAtpQ4ExcBFdr/h
uxUXM+iWBB7dZam3IhNgOHWIs5rbC8IbjWlvdEplVudRCAdyk4Bw7/89ATQ6HgmccqDSujheitsm
rYBlHhoDvzgQ0FfrpCRllQxSYH6ge/hWGHAgDehPwVR90mQZLFXuQH3XsxHihYp1kuEoW/CqOQ/f
8KI5fhW06SZf3Yzye9SNF8U+OLT3XXgA0Pkb2AWYdRArCpygzzqhxElsCmJK9sJw5Zz9mqc4uL59
QqLlgDxuNTdCDoR78gc+RCGgMR9gh8qXKh7ZISQ5llleMyiD4GIEl93MPtVVXtIa9mwzGmfS4M15
me0FZwYMfS1wqTXXvy6hb45DxyJvNpOasT+8ZYWzFDWqYOhdXMuwoBh9ZOQMfrAb3LtPW2TYqtMB
/3WUZgNcPHOLa5otYE44HaYrh0i9tvZkU5r7cF4/+MYUyRtguTU3fF8RMF32eXDG2wjOx0LCdtIH
tOt9qhvqyK2JFpdSK4oquyC2mxItwES2ESz/S4vqnTmp77fzg5hexlpsgLFdgFJKpal3pAQG5nTg
bcnz/odHN9ljUyvsNK+9HphMltyixube25D2TJDHwU5T6+hB4LVi9cU2ZOyC9os1fcuilDaRSkB7
d5XEtDW3Wj9YMubEnuv23kKbaNzQYy8kEHkqthDiTN37tkG/xfahXMNx6iIiSXhxg98bBbHMw41V
Sza5bp2OGhQ0dQjZENExKB1COuWscytRlwI5L5aXMNKqnHMH/B6r4gbsjJ7UzVuJOoEWgCCEVlgr
2rxazodLOPLxzxmcWiUvlXH+LeFYFE7DEUj/psxUyvV10Slk2wEncjkZHK/tcyAPDJM7olaKVLPE
xgF1MLxiqFqb4i9OoxBCKx/FnLAWQT0IPinX1H1GOVgTt8s2dtppYCFuXvtif3PDGJFL3ayPn8TB
p+C4aeD2eExGlVRXGosUUtJjaGgPGUn31+hX3QXDJcEAYaDb94AlkNCSC8XmJDP2OlFWKZzJN7d8
Jc6hvOu0tqDjf2RQJEfvRcXKHfsiQNZgdr5IwuTeBVk0qRd9b9PG+sj91lg31OsAJesDpyrDrgsl
C7+XpFZmuag1ZJW8cKlX7G71p75jO/OEMlDJmq6qx3iebYwUMfOoepejrSvok7RSEmRv39DN4CPw
jANmB1KcFJRbHc8pWzTrQTzuFB6UCFJNXDr5N0/HvCZ42gcpBOShzsDTuBydxnRmgRdyZ9AfdawK
wdqpOhgANGIEsQr+Vz2CNR0Pih7YC3Skuf7d6slk5VhPSCGYdZc1NW2Nl+sK5AaoqTjd44yIURiH
IyI280rImqFFjMVu8ElPbYm8Bd/7TP8/b+DcnSZE9ZRB5w8VNUr400msCQY7S8NJ/YQ4Ttl8Wf7G
JjDUdqcesy4gjpL4gDiu+Xy70xOaBY8MXQBPOkPBZII7w4OyKMs57gQsI8Rjjpze1TKFXQ/IVDZq
hhYzCXEViOeMbTl/cqvB3/fRdsajH5lnkV4SofrSXMPT9h2Gu1iaLMbeMhDGssM0JLecc0DBXfO5
w2axXdsws3tTr6u6fTFP3L6Jeh/rRZJDV3yFe0IquaNiHh49U7a3Yvs5d03L7+lomRqapqWAdbBd
OKkffMfRMCKVtZv4yGNXI1fcxD9R22KgAcEI0aoQ2vf2jyVBELtsxFNBD2tjhbBlb7cgV60poRnx
7FQjrIfgCgXyBI1d1yxJQOgbPCSTUc1OmB2bJZQPGv6cBknLh5rM6Qgq3Yxp29F3QeMxOXM7c7EJ
4u6QJ75dc1yP2F5NbSZnl6A/KtJwOgP37ewpzq6HTmw+RNDLPAaQ8qjjoVKbS4HhgmQwdV8ZHS47
glDWFoaO9O9pbXE4sV2FIeK1Kk0WOGcI/U1SWIEeWMbeEle7x4q5vbB7TIux3pNtrdUoFHw7QRiO
O9uMi9XHNj0V7Sutt3fMt1tTynfDdSzv6TWeav6MzUJNeaU5Qmq4Q1bQoEryzsmBsBTYZuzZlCbH
0RJ/jJlMGJyOAx+iTd+T9DF3DAFTZAB3yZn6J23z+jTAtGlPOB7OG704HaSWjnZPAnDuVr4uMaRe
QnBiM/dW+G1J9aIGnQIfyPVBdncrQ9mByOof1FFbqGQnMQHh1btAovnb9vFuc2SE6JSPRtkNtjS+
szsHSqiC58t0Jyc/dNMwjx3DHaNm27XrJJk4tmWnn9DFAdl13RtVwdNpeXoMNcBKi9J6VidE3fHI
6sPEESza+wmdjE+2k1Pu6/NoWfJPLzkRKdc0+rASVj11XDs3IlvZc213g+RsZm7QvhwJSyY6lAz+
Qe8rcoxKhp+jfju6+7OUZGm+09NrLMb6G7dA/PnnbUfWu0ZwgZLT1AfCJbwpRyaLnYo92ff1tJJK
wj6D4PFCjaPjMMFgr7jQCCglkj7rsNuAYxtG0Esas7E4y1qumBR4anQVcxLTlhcwzlHIU9jlIOQx
oGLAWfiEGd71GXuWDET7gLrUuov00bY3VLxxnq1NvmWjXS8Qo+97YldNgenMEKR7P4RGD/nYT6HZ
UInvRsinyUptor/bBaEZ6waRXQ3V7H4CXGknQBf3nu1O5HEtPc/jHhc7eTXdUzE9B4gHx1Mz02bw
Zjhc30jMmesD+kxDORs0lEWSA0Y818lw2bErhBXNmDSG18AVidrQ8TH3VrTHZ00ekI5D07n54nK9
OPnFiB7eBY1UvblvrRh+c7La/unDjmYggMuJu1tSywUPRsTqXNmc4XwOsxuTrCblpjhwph7Wbgy/
OmnaXuykSb21UnK3y05J0kGtAMbKIkatAKI2f00gIHQRdaXUpcklXGpN4nZtMBD1crXh1i66yuvw
dD8ei/10l6KWywLSh10CtjvpX/oc6KR/AVKL27XUXhoT2EF6rIOCGVet9TuXFuhJAb4AqSfZwFlp
hXaLV9gQbK2N6fsFapOEzUUPbe9r0b0U2r9lYyY3EFi6ddNqiNkTNZ6Unr8eR17155cR1MsDog1d
qwFvAOBg5MYIbPDHay9+KltEJXsOpbYLZJWo9bsO7+83QIDgqdIlGbVF9dW2FfveiUIg9lpqYrij
GfFCvqdlSMoBllD4JiePJd0vC8Tsm+ImAs1aFEzGvVy7P/+rMLDNyvGmMDGDX6Sj9DNe0LwgnXne
5eUrSqJb8NF9kK2QW2rD8Ph0y21w6WM3ZL6nCz6BjrM2Yp/HNmKPF64MdX8hmCqAsRv74FTa2YZM
yefgGcPJ4lPWZwzJpNqzQTlzQ9F4vqHd6Jrtx56xLATejshfdifxepRfMxfBJIw4D/U/XZJLiYsS
38yjSSHUkJLx39dVJN4X1J8xaDLUFmG7AfubdcrS+lTO4V1RxegLh5Ef6IiDVrNbbdbjygrvX8u8
p5l3/Uv+x6s5l40FYkUBJxVXy1lhIYYanVplscpxeCkKgg4cNA/W6Wwd3oYkCLAQZv2KICtQB911
HyznxW4D+/WWxWZ4sMdf7V22wuh4iwauMfduGpe0nwgTvN3rw/tLWl0XNFxcm9juCDKgWLVm4Vt2
c/GXNCCn2BOBedj0YTkrXD+MxjZ1C7yVyxLblzUtT1hcdrPryqNs8fNYcvC1v/iDDaeA9zgnj9YR
CyngYFkw3jFHdnEdGFllpnesRvD/NVYQuo+EyzHQrOBpb3tJj123RLqkwfY6uG92mBscVMIJWaM4
aTi7G05fDYyEQ0Lo29yEhpzxWvJENzgOiSS8AyCfsbksRV+PqoBbgHcHGKnqtz+wvR4bSaaE0Y+7
wL5QRo3XVJdqWS7mEwJjvFFD8mroMvhkMR8yHr8ChNSqWHftz12pt4ggTAW6um/Cm1aOWwxJDaEG
azFDLWt/SGqM4PiCy/VeaVHAifPrwlsHRhzr9dssl54+RvOldvdbeY+XCgw73c5uoZrz9AcMLjlM
xTFkmuHjLlH0WDnPB4kOvI0o5fNZGr4CKf9xXykyeIsPNE0cLkzs6hPDWY9WICw31R5ct9TnDcgg
ZOz+6C9z2Tn4klhMWjjH05UPRFVvzGOrY9xk/Pbp1e+vHBjj009X6vQvVxoIsYR40gn7EvPpDSxE
m8Xr9c3rq6/Fv1Rj06n87Q28aZ//pRo8x+pOGovGGIi/afYBRBa8d7IPTp0gzIhKl9tQ8R6vhAel
zZLAha23oVICIKmSQmlcE8vqEuis5slDmKDC+uyRxd6xL/8RVWN0GH/iQRETgoMR7PGBT1Oi2xQw
8CwErWP4RK8LQBNM6zFIYPBBty/b+2+3x7tn40zAWa4ZF/qUffl2G11CXWcMHh18NWKePRb1OZDt
/bTrHv+Qgw4nTAYk46riC6swrNzx+6v/A1xR8uFlbmRzdHJlYW0KZW5kb2JqCjU2IDAgb2JqCjU4
MDIKZW5kb2JqCjYyIDAgb2JqCjw8L0xlbmd0aCA2MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+
CnN0cmVhbQp4nJ1UPY/bMAzdjf4IjzJQqxIpidJaoEvRoR/Zeh1ycZor0CSXy7VF/30pyU6YXLwU
HmzQj0+Pj6QOrdG2NfkZ36tt8+YztZtjY9pNc2hs+dmOr9W2fbtggI1t0ilAcO3ie1MzbWsRNQVq
yZC2yL+2zVf11PVWm+CI1LIz2iGSS+pH1xuN6AlIHfM3kQ8G1brrnXEaGL3LYU8+RshhTg2GTFB/
KsQbmDIdUlQrAREH/RQHifB9JUeHdtISLbNIuIw/d0Da+xDU33w8aUNeHSqJSdGqX4JQqh0lhgiZ
JMe9SVyoNGB/1iWLPuaTvHYpcc1Gg0FM16rOhA8ZHbRNk+Oe86SSTTklgLRBQIdqK1K6oN2PDQkF
cdK2n8i2/GGip5AmfzkoNe6qLjDxorjlLYJ1rdgGx8V/W7xvgEAHJJ6uxcCzJHtcFVhg6Y9dD5GJ
oz/NTywtztEYUWLHPkVEnPSU70H0b3mGjwahd1NRCBQmX3lkSQ5hltxPmntrdfJQld8p4ansihZz
sDk3RoZfdz1i0I4H/qrhV26WzOeMdpqMy76cEKLT+459cQhB/a4AABYylufyXslOS7FD5eZxv8/7
4BzGvA9sik7Wzqpb17SQovqYw+AgMNsXYfmH/M13BjH3XVcpKTq5Gk+VxRkrjZLydjM7KGq/vBmK
qv+fa+6PJju3bzM3z41LoPC9vARKHeMeBGScnfbgYeb2epw0wcW0DmLOL/3KTQR782Yqma9E5ssL
tmzIXKrYObln+gwp25J4dEKMbe+91wlsLZBOZmTQu0XziZ9/BR9lG2VuZHN0cmVhbQplbmRvYmoK
NjMgMCBvYmoKNjAyCmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5
NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv
VGV4dF0KL0V4dEdTdGF0ZSAyNiAwIFIKL0ZvbnQgMjcgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+
PgplbmRvYmoKMjggMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv
dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0
R1N0YXRlIDMxIDAgUgovRm9udCAzMiAwIFIKPj4KL0NvbnRlbnRzIDI5IDAgUgo+PgplbmRvYmoK
MzMgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh
cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQy
IDAgUgovRm9udCA0MyAwIFIKPj4KL0NvbnRlbnRzIDM0IDAgUgo+PgplbmRvYmoKNDQgMCBvYmoK
PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg
UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ3IDAgUgovRm9u
dCA0OCAwIFIKPj4KL0NvbnRlbnRzIDQ1IDAgUgo+PgplbmRvYmoKNDkgMCBvYmoKPDwvVHlwZS9Q
YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy
Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDUyIDAgUgovRm9udCA1MyAwIFIK
Pj4KL0NvbnRlbnRzIDUwIDAgUgo+PgplbmRvYmoKNTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh
Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv
Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4KL0NvbnRl
bnRzIDU1IDAgUgo+PgplbmRvYmoKNjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg
NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG
IC9UZXh0XQovRXh0R1N0YXRlIDY0IDAgUgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRzIDYyIDAg
Ugo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0IDAgUgoyOCAwIFIK
MzMgMCBSCjQ0IDAgUgo0OSAwIFIKNTQgMCBSCjYxIDAgUgpdIC9Db3VudCA3Cj4+CmVuZG9iagox
IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0YSA4NiAwIFIKPj4K
ZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKMjYgMCBvYmoK
PDwvUjcKNyAwIFI+PgplbmRvYmoKMjcgMCBvYmoKPDwvUjE0CjE0IDAgUi9SMTIKMTIgMCBSL1Ix
MAoxMCAwIFIvUjgKOCAwIFIvUjI0CjI0IDAgUi9SMjIKMjIgMCBSL1IyMAoyMCAwIFIvUjE4CjE4
IDAgUi9SMTYKMTYgMCBSPj4KZW5kb2JqCjMxIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjMy
IDAgb2JqCjw8L1IyNAoyNCAwIFIvUjIyCjIyIDAgUi9SMjAKMjAgMCBSL1IxOAoxOCAwIFI+Pgpl
bmRvYmoKNDIgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDMgMCBvYmoKPDwvUjQwCjQwIDAg
Ui9SMzgKMzggMCBSL1IzNgozNiAwIFIvUjI0CjI0IDAgUi9SMjIKMjIgMCBSL1IyMAoyMCAwIFIv
UjE4CjE4IDAgUi9SMTYKMTYgMCBSPj4KZW5kb2JqCjQ3IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k
b2JqCjQ4IDAgb2JqCjw8L1I0MAo0MCAwIFIvUjM4CjM4IDAgUi9SMzYKMzYgMCBSL1IyNAoyNCAw
IFIvUjE4CjE4IDAgUi9SMTYKMTYgMCBSPj4KZW5kb2JqCjUyIDAgb2JqCjw8L1I3CjcgMCBSPj4K
ZW5kb2JqCjUzIDAgb2JqCjw8L1IyNAoyNCAwIFIvUjE4CjE4IDAgUi9SMTYKMTYgMCBSPj4KZW5k
b2JqCjU5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1I1Nwo1NyAwIFIv
UjQwCjQwIDAgUi9SMzgKMzggMCBSL1IzNgozNiAwIFIvUjIwCjIwIDAgUi9SMTgKMTggMCBSL1Ix
NgoxNiAwIFI+PgplbmRvYmoKNjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNjUgMCBvYmoK
PDwvUjE4CjE4IDAgUj4+CmVuZG9iagoxNCAwIG9iago8PC9CYXNlRm9udC9TWFRLR00rQ01SOS9G
b250RGVzY3JpcHRvciAxNSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNDAvTGFzdENoYXIgMTIy
L1dpZHRoc1sgMzk5IDM5OSAwIDAgMjg1IDM0MiAyODUgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwCjAgMCAwIDAgNzg1IDAgMCAwIDAgMzcwIDAgMCAwIDAgNzcwIDAKMCAwIDAgNTcw
IDAgMCA3NzAgMCAwIDAgMCAwIDAgMCAwIDAKMCA1MTMgNTcwIDQ1NiA1NzAgNDU3IDMxNCA1MTMg
NTcwIDI4NSAwIDAgMjg1IDg1NiA1NzAgNTEzCjU3MCA1NDIgNDAyIDQwNSAzOTkgNTcwIDU0MiA3
NDIgMCA1NDIgNDU2XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+Pgpl
bmRvYmoKMTIgMCBvYmoKPDwvQmFzZUZvbnQvVExJVlNHK0NNQlg5L0ZvbnREZXNjcmlwdG9yIDEz
IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciA2NS9MYXN0Q2hhciAxMTYvV2lkdGhzWyA4OTIgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAK
MCA1NzUgNjU3IDUyNSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNDg4IDQ2NiA0NjBdCi9F
bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMCAwIG9iago8
PC9CYXNlRm9udC9TQkJNVkkrQ01SMTIvRm9udERlc2NyaXB0b3IgMTEgMCBSL1R5cGUvRm9udAov
Rmlyc3RDaGFyIDY3L0xhc3RDaGFyIDEyMS9XaWR0aHNbIDcwNyA3NDcgMCAwIDAgMCAwIDUwMyAw
IDYxMSAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNDg5IDAgNDM1IDAg
NDM1IDAgMCA1NDMgMjcxIDAgMCAwIDAgNTQzIDQ4OQowIDAgMCAzODYgMCAwIDUxNiAwIDAgNTE2
XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOCAwIG9i
ago8PC9CYXNlRm9udC9QRFRQT1grQ01SMTcvRm9udERlc2NyaXB0b3IgOSAwIFIvVHlwZS9Gb250
Ci9GaXJzdENoYXIgMTIvTGFzdENoYXIgMTE5L1dpZHRoc1sgNDk5IDAgMCAwCjAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCA2NTQgMCA3MDYgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwCjAgMCA2ODAgNTEwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNDU4IDAgMCA1MTAg
NDA2IDAgNDU4IDUxMCAyNDkgMCAwIDI0OSA3NzIgNTEwIDQ1OAo1MTAgMCAwIDM1OSAzNTQgMCAw
IDY2N10KL0VuY29kaW5nIDc5IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjc5IDAgb2JqCjw8
L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sK
MTIvZmldPj4KZW5kb2JqCjU3IDAgb2JqCjw8L0Jhc2VGb250L0JNSlVMWStDTVNZMTAvRm9udERl
c2NyaXB0b3IgNTggMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDE1L0xhc3RDaGFyIDE1L1dpZHRo
c1sgNTAwXQovRW5jb2RpbmcgODAgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKODAgMCBvYmoK
PDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2Vz
WwoxNS9idWxsZXRdPj4KZW5kb2JqCjQwIDAgb2JqCjw8L0Jhc2VGb250L0FJWFlRQStDTVI4L0Zv
bnREZXNjcmlwdG9yIDQxIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxMi9MYXN0Q2hhciAxMjIv
V2lkdGhzWyA1OTAgMCA4ODUgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCA1
MzEgMCAwIDAgMCAyOTUgNDEzIDQxMyAwIDAgMCAzNTQgMjk1IDUzMQo1MzEgNTMxIDUzMSA1MzEg
NTMxIDUzMSAwIDUzMSAwIDAgMjk1IDAgMCAwIDAgMAowIDc5NSA3NTIgNzY3IDgxMSAwIDY5MyAw
IDAgMCAwIDAgMCAwIDAgMAowIDAgMCA1OTAgMCAwIDAgMCAwIDAgMCAwIDUzMSAwIDAgMAowIDUz
MSA1OTAgNDcyIDU5MCA0NzIgMzI0IDUzMSA1OTAgMjk1IDAgNTYwIDI5NSA4ODUgNTkwIDUzMQo1
OTAgNTYwIDQxNCA0MTkgNDEzIDU5MCA1NjAgNzY3IDU2MCA1NjAgNDcyXQovRW5jb2RpbmcgODEg
MCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKODEgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNl
RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxMi9maQoxNC9mZmkKMzQvcXVv
dGVkYmxyaWdodAozOS9xdW90ZXJpZ2h0CjkyL3F1b3RlZGJsbGVmdF0+PgplbmRvYmoKMzggMCBv
YmoKPDwvQmFzZUZvbnQvR0pEVFNOK0NNUjYvRm9udERlc2NyaXB0b3IgMzkgMCBSL1R5cGUvRm9u
dAovRmlyc3RDaGFyIDQ5L0xhc3RDaGFyIDUyL1dpZHRoc1sgNjExIDYxMSA2MTEgNjExXQovRW5j
b2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMzYgMCBvYmoKPDwv
QmFzZUZvbnQvV1lTV1BIK0NNUjcvRm9udERlc2NyaXB0b3IgMzcgMCBSL1R5cGUvRm9udAovRmly
c3RDaGFyIDQ5L0xhc3RDaGFyIDUyL1dpZHRoc1sgNTY5IDU2OSA1NjkgNTY5XQovRW5jb2Rpbmcv
V2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMjQgMCBvYmoKPDwvQmFzZUZv
bnQvQlNZWFpHK0NNVFQxMC9Gb250RGVzY3JpcHRvciAyNSAwIFIvVHlwZS9Gb250Ci9GaXJzdENo
YXIgMzMvTGFzdENoYXIgMTIyL1dpZHRoc1sgNTI1IDAgMCAwIDAgMCAwIDAgMCA1MjUgMCAwIDAg
NTI1IDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCA1MjUgNTI1IDUy
NSA1MjUgNTI1IDUyNSA1MjUgMCAwIDAgMCA1MjUgNTI1IDAgNTI1CjUyNSAwIDUyNSAwIDUyNSAw
IDAgNTI1IDUyNSA1MjUgNTI1XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlw
ZTE+PgplbmRvYmoKMjIgMCBvYmoKPDwvQmFzZUZvbnQvWUFHTFFEK0NNVEkxMC9Gb250RGVzY3Jp
cHRvciAyMyAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzkvTGFzdENoYXIgMTE4L1dpZHRoc1sg
MzA2IDAgMCAwIDAgMCAzNTcgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwCjAgNTExIDQ2MCA0NjAgNTExIDQ2MCAwIDAgNTExIDMwNiAwIDQ2MCAyNTUgODE3IDU2MiA1
MTEKNTExIDAgNDIxIDQwOCAzMzIgNTM2IDQ2MF0KL0VuY29kaW5nIDgyIDAgUi9TdWJ0eXBlL1R5
cGUxPj4KZW5kb2JqCjgyIDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFu
c2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMzkvcXVvdGVyaWdodF0+PgplbmRvYmoKMjAgMCBvYmoK
PDwvQmFzZUZvbnQvQ1pKVkZYK0NNQlgxMC9Gb250RGVzY3JpcHRvciAyMSAwIFIvVHlwZS9Gb250
Ci9GaXJzdENoYXIgMTUvTGFzdENoYXIgMTIyL1dpZHRoc1sgOTU4CjAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzODMgMzE5IDU3NQowIDU3
NSA1NzUgNTc1IDU3NSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDgxOCA4MzAgODgxIDAgMCAw
IDAgNDM2IDAgMCA2OTEgMCA5MDAgODYzCjc4NiAwIDg2MiA2MzggODAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMAowIDU1OSA2MzggNTExIDYzOCA1MjcgMCA1NzUgNjM4IDMxOSAwIDYwNiAzMTkgOTU4
IDYzOCA1NzUKNjM4IDAgNDczIDQ1MyA0NDcgNjM4IDYwNiA4MzAgMCA2MDYgNTExXQovRW5jb2Rp
bmcgODMgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKODMgMCBvYmoKPDwvVHlwZS9FbmNvZGlu
Zy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxNS9mZmxdPj4KZW5k
b2JqCjE4IDAgb2JqCjw8L0Jhc2VGb250L0JDQ1JJUytDTVIxMC9Gb250RGVzY3JpcHRvciAxOSAw
IFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMTEvTGFzdENoYXIgMTIzL1dpZHRoc1sgNTgzIDU1NSAw
IDgzMyA4MzMKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgNTAwIDAgMCAwIDAg
Mjc3IDM4OCAzODggMCAwIDI3NyAzMzMgMjc3IDUwMAo1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCAwIDI3NyAyNzcgMCAwIDAgMAowIDc1MCA3MDggNzIyIDc2MyA2ODAgNjUyIDAg
NzUwIDM2MSAwIDc3NyA2MjUgOTE2IDc1MCA3NzcKNjgwIDAgNzM2IDU1NSA3MjIgNzUwIDAgMTAy
NyAwIDAgMCAwIDUwMCAwIDAgMAowIDUwMCA1NTUgNDQ0IDU1NSA0NDQgMzA1IDUwMCA1NTUgMjc3
IDMwNSA1MjcgMjc3IDgzMyA1NTUgNTAwCjU1NSA1MjcgMzkxIDM5NCAzODggNTU1IDUyNyA3MjIg
NTI3IDUyNyA0NDQgNTAwXQovRW5jb2RpbmcgODQgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoK
ODQgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Rp
ZmZlcmVuY2VzWwoxMS9mZi9maQoxNC9mZmkvZmZsCjM0L3F1b3RlZGJscmlnaHQKMzkvcXVvdGVy
aWdodAo5Mi9xdW90ZWRibGxlZnQKMTIzL2VuZGFzaF0+PgplbmRvYmoKMTYgMCBvYmoKPDwvQmFz
ZUZvbnQvRENOWU1BK0NNQlgxMi9Gb250RGVzY3JpcHRvciAxNyAwIFIvVHlwZS9Gb250Ci9GaXJz
dENoYXIgMTIvTGFzdENoYXIgMTIxL1dpZHRoc1sgNjI1IDAgOTM3IDAKMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzEyIDAKMCA1NjIg
NTYyIDU2MiA1NjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgODQ5IDAgODEyIDg2MiA3MzggMCAw
IDg3OSA0MTggMCA4ODAgNjc1IDAgMCAwCjc2OCAwIDgzOSA2MjUgNzgyIDg2NCAwIDAgMCAwIDAg
MCAwIDAgMCAwCjAgNTQ2IDYyNSA1MDAgNjI1IDUxMyAzNDMgNTYyIDYyNSAzMTIgMCA1OTMgMzEy
IDkzNyA2MjUgNTYyCjYyNSA1OTMgNDU5IDQ0MyA0MzcgNjI1IDU5MyA4MTIgNTkzIDU5M10KL0Vu
Y29kaW5nIDg1IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1R5cGUvRW5j
b2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMTIvZmkKMTQv
ZmZpXT4+CmVuZG9iagoxNSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1NY
VEtHTStDTVI5L0ZvbnRCQm94WzAgLTI0OSA4MzMgNzUwXS9GbGFncyAzNAovQXNjZW50IDc1MAov
Q2FwSGVpZ2h0IDcwNQovRGVzY2VudCAtMjQ5Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMDgKL01p
c3NpbmdXaWR0aCA1MDAKL1hIZWlnaHQgNDUzCi9DaGFyU2V0KC9EL0kvTi9TL1YvYS9iL2MvY29t
bWEvZC9lL2YvZy9oL2h5cGhlbi9pL2wvbS9uL28vcC9wYXJlbmxlZnQvcGFyZW5yaWdodC9wZXJp
b2QvcS9yL3MvdC91L3Yvdy95L3opL0ZvbnRGaWxlMyA2NiAwIFI+PgplbmRvYmoKNjYgMCBvYmoK
PDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMzQxMj4+c3RyZWFt
CnicnVcLVJNnmv5jIP8vIlTxH7HtJKkIxfttd5XaOioq3qsgiiBowECQQCAEAsgl3EKSNwESuQaE
AEmAyMULoCAiUqutbnVWy663qWM77XE6zlTr1O9nf3bPfgHdcc+Z6ezuSU5Ock6+93svz/s8z88h
XKYQHA7HNXBncIDzix/zDod5dwrzSy6whrHRsQJXcOeCu0vnu2+tmIn6Z6B0TxTyFsHlcBJTVIGy
5Ex5fJxEIfSPmS9cHhCwapFwxbJlAcL1iWJ5fIwoSbhTpJCIE0UK/EMqDJHFxIsVmUL/DyUKRfIH
S5cqlcolosTUJTJ53Nr5i4TKeIVEGCxOFcvTxUeEm2VJCuEuUaJY6MxtifMjUJaYnKYQy4U7ZUfE
8iSCIN5LkiVvTJGnKtK2pitF0ZkxWUd2iWPjJPEh0n2J/vMXLV5CEB8Tu4k9hC8RTIQQe4lQYh+x
gNhPhBEbiEAinNhIRBCbiKXEZiKI2EJsJbYR/0DsJFYRu4iphBsxnfAgPIm5uEeEC1FG/MhRch5N
CZ0yzJVwO1zecolxue9az/tH3hlyM9lMspSK+s+pUVOvupmmvTNN6e7nHuP+YHrz9HGPfR7lHjaP
TxmNB3MTHIyrI8c6E7mMotjR2V7n0S5UTf/0r5euX60J/5jPHiMjVbCVLyUHDA36C3ABanTD2ovu
Pg4yDOSgc1BoLwlfQZusS9EqrjkAS+Dw5hwZpeN53X1Ksr4qVyl5q6IoXMA2/s1AW1XQL/BgKlWt
zAIrp+0x6n7MZTJQPI1m+7xgPVkvPyE7i53xwh95Iq9nz5Ann1WyYfQBEFkVZ1J6dcPQD6fgirWn
feiiuRuuQE9CY3yzSB8GIoiFPfJDsshIpQgoXC27z4EWWZlfOLJaZ74cRU2PZ3sdRFvR7+jOT0ca
e4G6d205S7C8oJUfRIltXamC3EYwQAMV5GJL6Tz6BVBoGpryBzQbzZz/A+sWeiAtWizw6rhOsv7O
Om8biw8LxiV/p84xGzjGOA4Omvs14/Mn7vUxIX3XoIoVjDeRsVrVWr5CylA8tB7NRf5oNwpmBWg5
u1EwTkl5qOA/OPRBralTwHSTnQbTAP8l7ylcC7PHndtjDgR/iIa5ezftDwpM3+Es9syrYue1cjof
o6ZRLjMPvaQP3g+ukADFurGchexs1uu5P5raO2Qe6ROwG38+c+YTORnJXqEhE0qyk+WHRQn7gFq/
4xvkiqjbX9291796L56i32tAvbz98hsnnDajTLqnCr2PeHwdqdUdy4NUKtmS1WxpNrefTGyP+lgk
2qngO/HygmTn/hW8DBtq9ENwFlp01yeyUZIbNFWn8FXzVVZmWROncwjlDnHRU+YDuh4q8tRayMvl
a7UFBcVqaZPUGI+L9T66ISyhNqU5TdApPV00VDCUX69pyqostGaAmFrpBzm+Kb+9nMfXVOqMeUDl
QGGmgJ1FZkFBtVGvbzjBLzNW1ZSX90b3a6wYA559d26eV9rTmgXxHXGm9bUp5Rtq4Ap1srn3O0SY
VssNfH0eFNcAVQumBpynDwa2lwOtbuT8NIrebuWie8w82sH6oh0yUrdKMm+BhpJ/zbaRrMtDxfDN
rhu3+VdkoeR6aVzcFvjmBB+1kxi5KmsObmzvX/aUEaI19IoD2wNXq/su89Ejkl3obN5d0KwQsAtI
2AaifkmbsqfoLFyCwea2a5RXhn41D/lXuTrIoALToAChV2cmGu7B8F4BU/gtF2Uxz+huQ/UDvtXB
i9YEwWH8CoLoUjwAqZV8YMiLcwI2Tpu3hi+X8npKb0Efft2CHo1zRHJyjba6G4c8o7Iwbzs4jYyW
i7YgRGuMWiOYKFs3NPAd5GGtQncIJJAEcROByQFoAHMs8mORt/HYcU0FVMBxg6kevYseeluGuqq7
9JSDTNREgRZkINXLDBOn2rT12ZAC+TpticqHLff2GMt6de3YHu7YDPQ13fRZT5nFeTZGo4WjIIYc
iJm8sU9XmwxKyNcWa4qWsqXefsiuroFSKJ1jcxhsOMdITTQcAynOMWHyxElo1FXlVKhqYkADWrUK
dAFsmvciVFNsxlxRNsd+ZqK2SFxbDL4rCeInz+F10lbHI5r9ybs8rzTfDGYoqyqrfI46vH9kO8ry
y1RmmGOG0sqySspJhlZlF4qztv2+yzqz717EE7Rm9E7rbK8IFfr+Dl0uaovrA8p63fxA8IlsL6mC
A3FxcKGOjwJJzH+dUT2xHRHmA0Ct2iTaLrVk2ewNjba+Q+U6gd12oaINqKEr4pWCo6SXjQjVrlNv
SQiUpO2HGCrgafJNPr7jKzg9UttKFfyaXrAu8dDBQ50Xv7jyL2ixkT8JRAsjtKLYXrziyIoZtAMz
6B0aj05fVdfZP1h3GiPhbKpNZDts2A0JcLB4X0pMWkK0dB9Egbgl9VSOBfSYVAv20o5DF2WX/8Kq
M/yfse5BByXJqQJMyzdf0eoEOseftJJOShNZ6x4xCjza33LRNvQTXVwL5WCgbJ1gwU0P1yp1IjyW
YDgy2fTz0KCtTkYrxklv+e60fUlB22COHLJqNIbj+tbj0EnZMuoU8sxjyVG9sZf+ue/TkRY+2sqs
qbKd6LlhmOMgEzRSyH0Ta/1aiIMSUJXklxT6sQXeHsxBVSvq/q5tgmQPPeEyBPNLOr1EmQNJVEqj
0maz1Ds+33R6JTtroZCdwdIv5iM3JDiJpldUq0CjAm1WMV+xOSQlDKjtAZcw5y97MHCt5rJW7mS4
g9DKeFg5fQ70mYPL+DI+dEWVE2SUOR+y+OxveCp2tWsrz/j8xCnkivvowmO7xqkCHBXUc45VACaP
J7x6FOwq4+Wz3NwwdgYmw6m813Tyi4kp4rytt/EUmTnI3Unumux0aVRkRgze+JiWlN6UPu1VOAkD
xmHb2aaTPY5h6IWz6XZx9THQQQZV+hmtNkYNf4QDewrnszQ74wc/NO3L832WE3iI20m08L/5hnnx
5kQ9xqpe842DWefgItXYSrqwWgMZONSH0lbeBbAW6YEa7yaTIcIXC8GIoVY/iGXJrLs8KUu+cMEu
YGpI5qPxl8fzyjES5tTB8QYBM0Da4cJzDIhQbbYuAsIhVx8yOb/nEJEsGP8VxlIknpukBa2dcBya
W051zKSbysHyY8j32G64L/Zh32Jn//l95IE8Bl82m9TGgnxNUYlOEO+7QpsNERBtV3QeHdRdg15K
30JXoCXf1rXCCFwT6dlZlAeadFbIYOUg19tPfsdFwxOsPw25kt8Nnu+rrNSWVPLzS7AeyqmUhkyr
/USD7bS4Y+9HAbvf57Pkh9L77L/9HQlEo7iOSjbajnZcf2BHRXZO2yco+27nJ1w0AwXR1mOO7H6g
vr9z6/6grDO3VnC2ewCqQa0pVEMmpTJlNNfWVVoachwxSVGqOAk/uelILbZJiwKDPgxrj6vLFmi1
MglEQnxdnD0z7FhMLBykNv4pGM1Cnn8evtuTcS62hR/StQcWYQJNgEJDkjHDjpFSV26uqKGel9Ar
4I9NdkNnfYvA3Gg3twL1LSxQKGDBckE/u5Y+iTx1HwSvjVo8f/3ASF3lF48Fk250ApScSZnjou1j
2+g3aaDu5z0K2kb+/63rFgiXSEOwdfVAp53D60XuiJh5HxHr8Xo8QTuYXTQ7z5nKjYpibFAsr8Of
N1j056AO78XghPqR20rKzwi8npUyp+n21JZEqUKelNQsd7S3tLQ7GTTNMbaslXPlBnp4g4uUzD/R
axpTbsA56ublG48QfWmhXy2/NEOvrp4wEBYBCiUb4XhekU6XV8TPzaysObo/q3H/xcXOVV61zPej
gYhyteD8oRNqNE32MKNC2xGv13XGwm4qKHzdsrUs5pqAQr7ODMbcCWujFLChpBIKq016fbWJX3Mi
P7fj0ucf388fxATi8fCHl1fSz6W2Cw6PRFVtM1MTrRjj9DpBzEU7fm4a/TAA9brB/+F1q9IsY+85
hTiJixKYH2hclBH0VPsQtOHtjNKEYXiJIFu/cXI7v4SqkloJUo+PeRuzS4vqcFNLjeW1KJt55G0Z
7qkdAKzhEg3WVExOSn345KlBXZMC638h1v98NmQ8ExuAp28+1sQ537O9BieebBBx7+K1kRNHNv0c
Pl5j6X/15zfA9DW0Hj2V3hJTHQmBEC6S7cu7GtO9CtZA+P70SMrroe6PvP/TI5EPa7D8e3Aj59l1
Lvo9W0BDuaa02MTSyO0I2gIoENDSdvyQ8B56u6zMUArllEldVpS3PJDlhPIjFqbOA3YaBFawvBHW
7Srr+WQDhpSpvMz0RmSUh0MPoTIafpOHpuxH3N3Ic8mX2ATnaws1aoPGVCT4dD+awr4L7GlgfVLY
CNaXfUerKSkBNaUxFFZWf3sHcS7zL/yh5UdA7k68sKEWtA4RHLTNijW6jsYmKOBXgSVqLJs6Sm0s
MlU9vIvcfp1y6ogkIzk5uSG5y2o26/ke6Hu083NOFbJz0Wm0k/6cte8knfDDob5BBBeFXabbUq2J
ianypMSW1PbJbUprYgLrUVKVsYnHRleTDrfRaXw3l1WN7lOtRnf30Tr36QTxXxFx1JkKZW5kc3Ry
ZWFtCmVuZG9iagoxMyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RMSVZT
RytDTUJYOS9Gb250QkJveFswIC02IDg0OSA3MDBdL0ZsYWdzIDEzMTEwNAovQXNjZW50IDcwMAov
Q2FwSGVpZ2h0IDcwMAovRGVzY2VudCAtNgovSXRhbGljQW5nbGUgMAovU3RlbVYgMTI3Ci9NaXNz
aW5nV2lkdGggNTAwCi9YSGVpZ2h0IDQ1MwovQ2hhclNldCgvQS9hL2IvYy9yL3MvdCkvRm9udEZp
bGUzIDY3IDAgUj4+CmVuZG9iago2NyAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5
cGUvVHlwZTFDL0xlbmd0aCAxMDE4Pj5zdHJlYW0KeJw9kntMU3cUx++l0HurXYe6Kszt9spjQ5HH
ng4kW7Q+Mh0OgY0OJlJLB5XS1rZQymMWsVB6ShEEgQ3XkTKcFFCeIdAhUwzzj+2PATH+sWzJYqaL
W+Yf27nwc8k6siwnOTknOcn3e87n0FR4GEXTtFiZuV+V9m8VJ2ynhefChOdF4Fy9v5oVAVIRSMPH
1uo2o34TnngacyMpEU0bLOeURpPdrCsptfIJmp38S2lpe3bzL6empvH7yrVmnUZt4DPV1lJtudoa
avR8jlGj01rtfEJGqdVqSk9JsdlsyepyS7LRXPLmzt28TWct5bO1Fq25UlvMHzIarPwxdbmWX7eW
vJ6VxnJThVVr5jONxVqzgaIoZp/ZYlWf0lBUDJVD5VLvUfspJXWAYkNrUeFUNXWXLqOvhSWGtYf9
Lbhka5EQxNigcNRHCx+vviZ3DNSCPRS14DCRtie/RZ2vAbfZVd1c5a4GtjJffKul2zMPYxCAO66v
pLFBxgQ6MF66iVFReFW8SGIjkvLFI94/YAIm4ScYXR/axZDHgl6OEjIUQc6KZUJtSPXRAo00ipDC
LSI0oUEOywPIPvI6HI3VUMOeHLFdCQT6JufyhrIOFqmOV3BupMVkb0NEPrN4EYoV5PbhfGbF2waz
0A+3YX5d6XVGJnzkHBe2XKPHVvD8ikjYIWTIL8MlW31NQ72dK+spbj0NrJ68AiQqBrdVjDgVP9R9
64BsVpkEFaoj3b8YuMZet7cS2DPgtCh2MHZw+NpboKePG+id0c+DD6Kv4quAL8wZAvZPFIWjZRcy
ugsuvtMJ0+ziA+jD8NYsUwvnqeuBTmD7PRf8CplQ5JzCtSC+5aP/RAlunBOhRVDIMTFIEjFHJXYn
fRgX72I1P5J+hoh/r71zb/bWMjev+oA5UGI3H4dFPycTlpzjmD+ML47Ty7gV30CJSKjCOfnPyu9I
cjZ5pjmlcLhycHjQP/Flda/Ly3W2+FuvA7s0UZKhKGNIOskoIqIE3FS1dPfG0MyA4gwU/MUFxZ/1
QL+/BuoVRz0hv36WSG7KYwgLTSr10PTQ5XuY18HJVuNDN5WO47v/MevF6BCz1SNycvh/Hk9+nWNm
FgJlQf33EI2pjx/is7h91wOSsPd9XV2Voi1H3h+YDXwDLEYCkb6thrzKEsXpnGNNNsgEzWhlgJUJ
fc4pQTJFj2E0HsStIsGBrPzT0C/awG1v4GwFhcYsYEkMYNz0ogcjcVv71+5Gd7PL7VacczTVQB17
atAyPDj8+fRDwkMxyT1EZIQmm+/HY/r1YNsXk9zCSNcN8LKys11CVgee9HV2icmJdia4ASUbuQ3h
e3xSyXiHVIqSK9KnPFIZRf0DTEvYYAplbmRzdHJlYW0KZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUv
Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvU0JCTVZJK0NNUjEyL0ZvbnRCQm94WzAgLTIwNCA2OTMg
NzA0XS9GbGFncyAzMgovQXNjZW50IDcwNAovQ2FwSGVpZ2h0IDcwNAovRGVzY2VudCAtMjA0Ci9J
dGFsaWNBbmdsZSAwCi9TdGVtViAxMDMKL01pc3NpbmdXaWR0aCA1MDAKL1hIZWlnaHQgNDQ2Ci9D
aGFyU2V0KC9DL0QvSi9ML2EvYy9lL2gvaS9uL28vcy92L3kpL0ZvbnRGaWxlMyA2OCAwIFI+Pgpl
bmRvYmoKNjggMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5n
dGggMTY1NT4+c3RyZWFtCnicrVRtUFTXGb6Xu+y9MSux2nWwknvXGm1Agoq2BGLN6GISiBALUltE
YF0Xdgn7wbIsrIXC8rHs7rsru4B8KLsLLIQFFQOIrkVbCUPUhNhOM1NmbD46Nm3sJG0ax8m520M6
vYLpn07+dc7MmXNmzvvM+zzvcx6SEEURJEmK5Vk5O5MfnbbyG0k+Lop/mgJcHMmIHI4GCQUS0YU4
+pW1qOk7qOQp9NM1BEWSuspGud5gMWpK1SbZs8p42c7U1JREWfKOHamyfVqVUaNU6GRZCpNapVWY
hEu5LFev1KhMFtmze9QmkyFt+/bq6uokhbYySW8s3RufKKvWmNSyHFWlymhWnZC9pNeZZNkKrUq2
3FzS8i7Xaw1VJpVRlqU/oTLqCIKI0enl6ZXmTMVBi1Kl1hDEa8Qh4hliC3GYOEJsI/YTzxH5RDrx
EpFBZBJPCWwJEWEnPiPzydkoddTHVCp1XbRGNCT6Ojo/+p44hbfH8FMQ4uMCJCIWkHKB4n+CWqVw
H0ZM53STBV4NJIDq+aZqxvlAjOMaonX0bzua8zkcpAsbIJPV0cPuWRiBEMzCsOO6ZHOIfrUewhzK
ph/+bu727d6fZbO4/lvf/hyM4BxlYvg66wCfHCBHF9HoIsUXoTIpksY/wAyWJG7Ca/F3v9iGxGjV
539Ha1lchgulJVB4VnfNEHa+DdMwAbfGwiOXr5wdh0mYtrxxYuwYHIQSUENWRYH+6LEaFTAxkSPm
UGR7iJy9z1cOUxFZ5MdSH3isLU6HtYXN31M49/K4HDbgV3GysIqxEu3GO1AGev4+2oyiusDbYHXa
mrlGvAszBxKAOYBzp1EYTaNDV95/+GkyTghw7nqwdwPTC6cCXEykHkKR6BCJnr7Lr/8rNR15UaoL
0O+fspZwSyN0id0qZ6t16IEYvYC+hxJQFsrDG9F2nMbh9V9/X1rkaD/P8dP0eXf7Ffah+CN4T3kp
I5wOW0EJuc7ncvaVKV47niKw4tdbA/yPfOT5MLKEKfQB/8Iyq6aaqsZmtnyo3Ps6MHh1acbhBlBP
qLlz+gvNVxvfauixD1X7anuqQM8UG4/uyjg68UUV2+oDl9PlaGsFOzANYLNwOI62gO20x+Xq72M9
7eA+c3aiYBb6gHn4m/m7s2XnGju50jGDN6Nb693fCzeZsf6rf0GkN6nczbqa2uEUMF3g8XExfI+1
n98YIn28ieIT0SfSzoG+y++6mBCtc9RBOZihFo65BUvo6GmHRwsN0Oiw2eq34K5YLELjtl4ngGfD
8AT42BBtdBwBA5SBA7JXSubgdGt3OdqM/xXrqXPbuqEdvO72PkEdMAduPeDrQ+Sv/4G23aX4NfxX
0sk2z51lFDnoBJTdYFhGGaM/OVVfyi0V0ckFh/LMhzrmteyobdQHF5ngL4Y0poq6kvSFrHsf37+J
othHhg2gk/6hD28GyCu/R8cXFgcofj0KSAVvTxVNqs8V9hYBk3owL1PnrxsM9vUFL5VCLTc4PeOb
Aubq26qdnJLGx+wvpsBeZs+nxlvvhadm/GxbwVjpZWD653v/yM1V5dI5lU11Krhxhs28Jo3fX1ac
f/ziDIpFe7svuoUe0GOLxX1A8XdQp7RKbP3BL/E6LAdmt3jFQhfoi+7ue+xoSKxz7BI+hBaSoXKZ
7/+YkQexMCdcHPAt8g0h0v8Hio9H96Rv3PmVyw+PJ/U6mATZc1dkf9PRaQLLo0m1WrdgTyym0FBL
L3jBtWF4HAKCxhWOfNCDSijJWSmZhw5bTzmKX4qKLdoEjtamk1qDqhCY8hofcDDeNh6s6bGcNFt1
qjdLbsxduvbOsOCdl60DKPTh7AA5vogKP6LQv3mxtL4Ejlf2nQwO+ntDdw7MpOEnkjY/yonP4lE0
ih1Fks7OZrA3Ou31dq4qPU+bB0x22g2UiNL+dOn6xFu1JwYfAxv8SL6cO023KX4dqpUOuMH/z7y/
4dVYvOsZvAbHfpmAKPRkGBH9XltbS5PgSwdXkfKKSQGMYusI2sf5aZdf2oF2/tk3Al+BF29yaZhv
UhVppr41WH8Iysy6csaJvhRj7r/JutT/f01WFBT6YKbQus9JRL5Dof38knTYPKivqDIbtMGa4Jhv
eIDFLM6W6uh3O1uEZB/6BnPEPSMgdsE8XFjBzGz1THK8iI4x9/PyM0h/uqNfjBVddGjVwpPsKlFK
QPJEoFMiWTgrWU0Q/wFRWnkTCmVuZHN0cmVhbQplbmRvYmoKOSAwIG9iago8PC9UeXBlL0ZvbnRE
ZXNjcmlwdG9yL0ZvbnROYW1lL1BEVFBPWCtDTVIxNy9Gb250QkJveFswIC0yMDQgNzQ0IDcwMl0v
RmxhZ3MgNAovQXNjZW50IDcwMgovQ2FwSGVpZ2h0IDY5OQovRGVzY2VudCAtMjA0Ci9JdGFsaWNB
bmdsZSAwCi9TdGVtViAxMTEKL01pc3NpbmdXaWR0aCA1MDAKL1hIZWlnaHQgNDQ2Ci9DaGFyU2V0
KC9CL0QvUi9TL2EvZC9lL2ZpL2cvaC9pL2wvbS9uL28vcC9zL3QvdykvRm9udEZpbGUzIDY5IDAg
Uj4+CmVuZG9iago2OSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUvVHlwZTFD
L0xlbmd0aCAyMjYwPj5zdHJlYW0KeJy1VgtQU1cavpdg7kUorda7i1t7b1yl0rUCVrqKpbaVFouK
D16+kRBSiBASIDyiFJQAIfkTCAHkEQIEiAoIIrSiMkCKVq2s266r1eqWOutqW22tdteeyx53Zi+w
7XQ70+7szO6cmTP3zvz33PN/33e+75CEuxtBkqQ4NCJy8dKJp2f4p0h+jhv/tAhw/HjeeOQ08BKB
l3vXnOkPZyLrDJTyOIp9ghCRZFpmYahKrc1QJCVrJH6yZyWLg4OXPid5PjAwWPKqUp6hkEnTJBFS
TbJcKdUIL6mSKJVMIddoJX4hyRqNenlAQE5Ojr9Umemvykha8exzkhyFJlkSKc+UZ2TLEyVhqjSN
ZJ1UKZdMbs5/cg5VKdVZGnmGJEKVKM9IIwjiybSVKvVrmZocaaI8KTlSEZWq9CKI9cQ8YgOxkfAl
ookYYjOxknidCCPeIMKJJcRqIoiIINYRSmKW0DzhTrxFPCCjyY/dlrtdE7GiS+5J7lenBYs9xaVU
MGWmX6K1HoEeo3ypN28FJy+xkfddKNEl4peg08zQvjE8PSRhnSyPNd4X4+l7p6VTZ6qKt3G4g5Lr
S9aw6VSruR+cwjgOrYZBr3lOao2+vJdD0dRnpz78w+XK8G0s1v18rff4r8GJLtvQSSeJfM6j25dF
w+MvM+nUh/shjnt0lIrbC2FsOvqSQrPGbt++FXxVYuXuNv5+FK7QY8E3MMPiUHyJQZVUl9nSx6JZ
4nv9L0a8vO5lTHC++BYjM1i6ONSNIqhvBgNXroxciknOm4/T2fkgG3lgFB0aFfGhaBeDZvl/jUlM
+i/As/DMzxciEpGf30UzWRyH45ntIDuo6c04XnoK+uEd87DzeNPh3s4hoZejGa3JHdshHFIh0bBe
vU21Iz5XDrSAJ97kRC/Y+EA7ec+F6kZFSI1fYqbwWU8dkr6jdgH99f2baA6aGXR3/vqtu2Qq7hKF
Pb+H+ZHyJ6BbxVcwUAfNvT2W8q72QaAvnQ3EYixe4x+SlNhwUsnlO6ACbLT3eCw4xz0ngB3lf/UT
wF6k0AuIQX5oA9qIn0TP46Uc9vmH7xRw/OC/YHUXj6FFW3EbnpsQmavmMlMjY54TukRYZ+OX1ZFt
R9DeIyL0Pr+csRtNxXqjMa+ALdUX7ivVp3TFmXYDjUWyjRsXP8g+VMydz3fom7W1BY4sSKKlmTEB
QakXbmrZ0jow6YDWGY05HJ5PaU3GCovJVGlhK6rqWyuqm9Td6aeAvud69+Mh9YH8Gk7ZkWyVVkbX
vF4H52hn3cj9bysWpJhZU4nFWAZ0FZQ1cN7oW4Fo1omCm8ivXIi1i9BC3o9BEieWoAit2DA/efFv
DfSeP+MuKhewO6LPdL13mT2tjaLC1DukabKm26z3eICumX9KAPHUeyL+GrrDNJ3pM9ebaCeVYxQG
5EI87DYLtKRTHYYGLWRAkaHQULQIt/n4ogGDtbQSymc7u8DGOimNQQqZQkU6aKa+GAEwNK8NwM0+
fuidklowQ9l3tZlCbQZkgQKyp2r7YX/p/l3ocfzIpzy/TFjWCuVmS/03aMTnr3jEkldusMLsSigr
K6+lJyRuQ3tsTX+8ZiP7zqEE15+E5h+hGgYuQLe0983D8dUKoEMiI8LfbDdU1LZUHmzL3b9bX2I0
lnLN59+1dwM9OLJzKbeT2mB4TRelXJus3QJyesWtLNfIUMdpB2veeVDWD3Szq+4ad0obSa1T6/IT
YLifjW1lgiJ2Rm9J7DnRXut6r5MdODBS3mmeOBKCWJ63IVUPeXgU2YZE6PikIKc8JZ/SWxJGlwPt
6xeIffAvPw/46kb/BauFW0mhxyqnOakNhRUDHP93KvbRRQaUWrUmR6FUlOQCnTavHkWhzYiucZ7o
SU9q4WqzoRS0wg9/o7OjrHr02uRJLxJsbQYqYMrLBZSr6Qcxf8HiuUufwY/jX9xZ+BC59z9sthaD
ochoKNCzWauiFZsEYuNb1f2pQ3AGTtKmesaK5l/t7IMP4MQaE3afABnHN6Ad/bcakOp9sqmvqgVt
OzPQJ0Ii9AbTmHd4dx/Q1z54f8yp61N2cAfb365ugXLhaFpK9cZCPeyh86sKa+srq2sb85pSZMm5
6SpWeSCpOkUgZlXEssjDSdX7OGUyJEAJpFfLu7I35SfIYAsdeicWiZHbvaGP0BzsBys0CWAqYVMt
2QehG6rA0eigP8tjlgAimpqE6eZNwEROjjAt4Zz4b8yCMNdIR8Mhh41ra6gWmqE/QWLwjw6LXcB9
FwMTHP04CYJl4bsKWCNC4h961P80CkL22IQwOGdDZyc9Cw1c+dIu4uegL5g7jddH4Tr9xdwbWMJi
R7r4312MOmQehg5hDMOhqRXD9sJxDtmQB3UaOjV1+X2JoIZV8AYo2hVHE4b0DqAv7x9rqABroc5Y
rOdKVqdlpUI0FJ8vPlfabKg3OIoHdZew5xE6uIrBYtQsnjTCS+KxL9PwE5iZm/GKYC9mAS3PHvT0
J+QDQc4B/CPGoW3UZOVqNVn23BZHo72FxR54oyDyU5U/Cs5j0Aat8Da0TO13g6HiCMeLKYGBPc7x
Ra3kiQH00YCIXz3+4qSlFhv0hXpWGS4f2di2Fmb7Bi/3TbXu7JJyPTu6ddez23WD+dX605nt6yGK
Dt28Ikiy4CySFLFGm9FU9J2pxk2aqtVs6ahjTWVgbjw6GP7pWwNAI/Lq7YfDuX177Zx0NK5mW01R
mQGi6mLqNNaMA6qOfZ3QSf9u+OKNhxdewTPq2TJhGev3FmueyJieSQAWja9mflIcbQLh/T8ivPYH
l44JtY0vE9Q2WPgp9ly1fUeMljWKCz7ZYI+CEEhYlyej/3/XkP9Kp7xe2LZ3N3r6Yq+NvDeEtg6J
+Hn8GibT+GpJrqHYaIACIfDEyEN850r/2cZjJQoHuy8FkjNtBU12e/WBwW29ESHYLQ67cdjjxfTr
+ObP44RuogXUscrCnRzu/g+I7rHxK2uQqrLOJsbxVZRzusuTne6uVXl52Kq9vFy1Xo8RxD8BDSJO
6AplbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h
bWUvQk1KVUxZK0NNU1kxMC9Gb250QkJveFswIDAgNDQ0IDQ0NF0vRmxhZ3MgNjU1NDEKL0FzY2Vu
dCA0NDQKL0NhcEhlaWdodCA0NDQKL0Rlc2NlbnQgMAovSXRhbGljQW5nbGUgMAovU3RlbVYgNjYK
L0F2Z1dpZHRoIDUwMAovTWF4V2lkdGggNTAwCi9NaXNzaW5nV2lkdGggNTAwCi9DaGFyU2V0KC9i
dWxsZXQpL0ZvbnRGaWxlMyA3MCAwIFI+PgplbmRvYmoKNzAgMCBvYmoKPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMjc4Pj5zdHJlYW0KeJxjZGBhYmBkZGR39g2O
NDQAMVV+SDP+kGH6Icvc3f0j4EcAazcPczcPy8rv3ULfYwW/R/F/DxdgYGZkzC9tcc4vqCzKTM8o
UdBI1lQwtLQ011EwMjCwVHDMTS3KTE7MU/BNLMlIzU0sAXJyFILzkzNTSyoVNGwySkoKrPT1y8vL
9RJzi/Xyi9LtNHUUyjNLMhSCUotTi8pSUxTc8vNKFPwSc1MVIG7Tg1DO+bkFpSWpRQq++SmpRXkM
DAyM/AwMJQxMjIwsmj86+H50HF7w/f18xsM/xJl/BHzvE/1m9EjpN4OJkZLiI+PvDF+ePPomx1e8
+Kf9Qrbf0tPYN3Nt5pbjYhFLq+fh3DybhweIeRkYAPQkXX0KZW5kc3RyZWFtCmVuZG9iago0MSAw
IG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FJWFlRQStDTVI4L0ZvbnRCQm94
WzAgLTI1MCA4NTcgNzUwXS9GbGFncyA0Ci9Bc2NlbnQgNzUwCi9DYXBIZWlnaHQgNzUwCi9EZXNj
ZW50IC0yNTAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyOAovTWlzc2luZ1dpZHRoIDUwMAovQ2hh
clNldCgvQS9CL0MvRC9GL1MvYS9iL2MvY29sb24vZC9lL2YvZmZpL2ZpL2ZpdmUvZm91ci9nL2gv
aHlwaGVuL2kvay9sL20vbi9vL29uZS9wL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3BlcmlvZC9xL3F1
b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0L3F1b3RlcmlnaHQvci9zL3NldmVuL3NsYXNoL3QvdGhy
ZWUvdHdvL3Uvdi93L3gveS96L3plcm8pL0ZvbnRGaWxlMyA3MSAwIFI+PgplbmRvYmoKNzEgMCBv
YmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggNDc0Mz4+c3Ry
ZWFtCnicrVgJVFNn2r4xkntFiqK9Cm3nJlqtYqlb6+64trihU0VFKYjIDoGwhF0Ia0jyJiFE9n0L
AQyIC6KAu6VqqXYqrdbWVh262FY7bdXv0s/5Z76Q+rd/pzPz95w54eQA51uf93mf57lXQI0cQQkE
ArvVG7cstP7yAv+sgH9uBP8HIWD90L2hLDtwEILDyLbnJl4fh+46IeUY5DmWEgoEkTEZq2XRybFh
IaFyyfQAV8mcRYsWuEnmzp69SLIyMig2LMA/SrLRXx4aFOkvJ39IJZ6ygLAgebJk+tJQuTx68axZ
iYmJM/0j42bKYkOWubpJEsPkoZItQXFBsQlBgRJ3WZRcssk/MkhiPdtM69dqWWR0vDwoVrJRFhgU
G0VR1JyVUatkq6NfjYl1j5PHJyT6J+1JDkgJDAoOCQ3zjJBGvjJv8oLF03ymuzq8NHPW7DlzX3ak
qMnUn6jnqdepKdRmaiq1hfKkplFbqW3UdsqL2kGtonZSqylv6lXqDeo1yp1aQ62l1lHrqVcoD2oj
tYliqQlUIuVMPUsxVBg1irKnIilHagw1lnKixlHjqacFo6m5BFNqJKURCAWpglsjtox4X/hH4eGR
E0fm2s20i7V7S7REdI+OZGYxTaPmjTKOumsfYP/maLfRPzokOrzzVJzjRMetY+zH7B47cmzU2Pec
RjutcTo4zm7c7nF/H//0+FfGR46/+/QrTzexMyY8y6schw6ABe2w8K/WCPglQ2tZZamqMAWSQZWt
TMNxj287Z0Yn7F4ETDi9X38aqmA/tECv6oTD8xbaTxtTA81gBJ2hpBs5OaNG0Tk83aCAPFC7RHqB
jAunb+l1cBbOkYlvDk9KoT0gs1Cxn8GdfAmLxuCP7DCIHPk7YOHHmgVo1DUUeU3Ip6Bz7KdBZyZP
37U6TsFpvhbhqRl24fSVfTneYlxB71LABrL4UX0XNJETdMJR24k2KOCYGK2jH3zUe+FC+W4PDif/
+7GOQznk+hfMqM0iQK630KffCHuGlrPhdfR1XUaw+HEVHazOWMbFh/NuIsTd+8tXHy+7gZ3KxEhQ
f+kduMIMTvsIP8Ph7fgyi3LoNp3xOIfEovvHlr2+5k/LsEiMBXiQ9VUb28SoBvnR35z/49LFa1+b
KnbkzZmt/CSzoGUQHRsU8ioUxiKnKYjCzth5CqawE3Z65IqeRuzDe8iJwwq8ld0G/qb49tgjql44
AQfhrdajpvbOmm44BUdj60Ob/LXbIAB81Vtl/tEBu5L9gHEc2pdgGZpmEfT9wBvbhENeQ4vZCihK
z9Fo0rO4HStDDq3rfRFcsC9eiueR711oCZ6H/NBSNAK5IMciKEzNUCkzNeJsPBOPXT0JmPl4yynU
iurQ2re+uouYtXiFSazN1uaUAVMJxmpyrTt4uwW9aOafaxUg4TXUOihEFXgeayvMIrp7x8ns/cCg
8WjEPXI7pxe+xU8Fbs702iG+SGNXa4nfM+T6ix8H/YuyLecb2PrDJzouAXO9fz5Bl169cHGob/mJ
CLGiErRQTS59ilDpb6Sc0wb5uX8VHv/tco4VobVoKpqBNqJt+AU0C68R48l/42y14vf/VEpa9CH0
R3TtfHs5SMAbdoCrx8rQPRsC5xJw+fM/X7V9EO0nrI3jN7IyUfAr4affaPMgwDrhETMwi52+n4bG
XD1+uKVBjF/993xchYpZSIXcvTHBm7bvDQNmiccgopDo/Y9vfNyzeCsBeC65HdVFwB1AQgKuB0pi
4YNWRH2ty83LzAY5I21Iq2morWhujzD7rffz9kzgNA9EePJvtM8h/VlogD7QQf/wERLpVeriA6Qn
1pGe6LKgowcEaOoXyK9VyP99aCn7+Gp4nciGY/kTHEXW/r4M3TAAx4bXiKBfgrJ2MVJ+Sd8rkc4T
t6IaqWi+IsKVm4l0IhuqLiK0AKo9KvFEppW0/oJMMz+tUdB+BuWcESKeXzhMUqUKUlM5tSYrSwUa
UENufmpxVPEuYLBEuvyNnR1RepX4cGR93mVFd9b1NFjDBMb4znoh6sPT6VxeqYaIEJMK2UliPJZO
hczSAq22uoozGIpLDYZje7rVJisHuwbe6Yn6Mx5dJ87WeRblgdToUwuHmZa6zq/QSMMimY7TZhtV
RmAqbNyeQ1r2KQtaWCNAI66h51qFaBM/mUWuFuyKPKQizew9bjNVjOwzbKLxqM+Sj18+/NYH3Dnp
NtpdGhy0Fm5XcKQ/yGXHdD3ROXSHX8U+qcsqep6Xx4p5eUdPcOgTGrtZK3YNVHPFeAa9GmaiV+4e
uFpo4LSLRci1yM5Cr8k29orRA5owMbOWn2gR8H9CH7MN59pKO7SMhQ5VqWEPZIEPSPWkMuF0u7ow
HlIgU63MyyIKY3DG9qghtxQKQOfSeAAqOQu9W+UDSZAAb0CEbc4FMOSWh6EZ+L6zcW8B6fMyMO4z
lFilxbbn0HT0CVtYX9nVZ90znOy5GyIg+sn8LnVxDDEThSpXneOGdc5TkElZCnrIdzHt1zaQHQNV
2yET4slJI5/sqFNWb5+FwXk6KtHk5xWTsU0HoWr4dLvI6ZJJG0bZxp6AorxiGXoGP3Au2KvPqoBK
yC82lD5Ebc4PcZshPT+jElwqIL8ov5ixKq4ZxTZZvjCZBV03UdS1AcLrhegke8/txOyFKyPWRdYm
m8zVNU0NeyvjDVxH4xnibMy5c4GLxFJ6s2qt6rWol4NSNkM4M++vMe8OHDtyuI4zBJmCuoApupX/
ufisdCu9Z29qQjAcL+aWn2RnLIoJ8PJr73nn4hU020BKf550roDo0gWUzprbm9taLJb2dtMlK26B
BLddoITXn9SqWp2vgHRIVyoUaR4rnZfeVZRZfdYFjAXljdYZASpPyBjG4ifcroBWc2rT99jJebYk
Vha8Z7naJZzu0BuJwOjgAuy3iUy6LsNIvLiqpExvaGxpajE133R1rpGT/sqB7Jy0OA1jVaZjUE0G
nYQW26SNkGmIaWVs5BWbUZBNftqs8jO0nrXp9jCHH3/eSh+42BDWHXQFXJ6I/Lgp97HjUu/dySli
/QaWLK0rr2ru6K49RpzrkLQmsjK6LBRWgRxeDfEJ2eWTHk7oF9AYc0hRbRN0IrS7zfx7FkHtbSGh
+Cds4/mOIssTivuTtLH9CSGa1WWpZKFcTY5SIcFKZ8yg8pxyAkC+S0Orto5waJdqN2HbLxh+CsrU
lUFoLv7RedekyNdeAyY2tQTERl19MTQz5oTy+ER5utTvaPCZwZ5HRfmkjtLMVnTws+ph1Q+9K+RH
8pNYWVaeHBRMdHWi2VRb1XJxTctLWPwSFuLRePwP09E4NKkd2ZeUpIMqR6nJVHE5CbKl04DZOLcH
TUdT3j8zUHgaktuJxkihlWdILOAnCfmXeQlrLNTpYB9ToYBUDn8pUuAldq2igh/q2tFIImEiET76
eEROlloNWS4pxaSH0Q+iKrTNTirKxEySLx5D9HK06JeVI4duGxCim1Zb/El4QujQgz41XmSoExZa
DWvMt1PRuL5ec7tF7EEjt/8VG/47evnjyyyhXd7eRFmAb5wP+EJAQ1xH9CFlLzGBNwuP1Lc3dBwz
n4Qe6Ilr8WJsaAWY0MLhqGO8IuTnEMeqK4D6Qe+HeBIeO2MKHotZRE0jII0/8ag+X1WUnqHOyVWL
Q2bMUyWTtvCtjTweeRzehhZGa2ILkeRWQwegUZCPJ2nljCO6PtxXSE3So/3A158JkadVlR0seAyy
E93pPdZVUZinyeeSs5QpkM7EVCeZmqqqTUf9m7evmLtNwuGRi8Jv4oH/ZIq8Gfs3o7X9HzajjGZB
Sx/KvtHWJ0Qr32Wl+tgmOAANBYXGws7YQ8oGYO4PvPvhwZT9cSZxWYmltlebp1IqIZVJLk2vKqsk
apne5pfyRp6/LxdbFVjpA8z0Ve5/9DGF1iaK42OzIyAO9tRI61K80vYEgi+z+ntP5Iyc0IiTN85E
dIZXcq+3eoMrMMZH7Ez4uq7DYCqvEVfWm0uagPkSXowPVsbsJQvJInKSgenGK9gmNBGWbFvmO33a
8uNnaiv6boqf5O3hVv5V5H7Z1zMimdOgu6JfNnbpfzFzo57hDIMckNBaMiHy4h+zzfKm8KgYeURo
c4KpvbbZxOEZeBOh6NuFuYSilT+X5xyUQym8Be22JdfnGQ6JeYq44B0Sdme0CPouoXuXhCiNJ6mz
3OckXGAuv3npDlpZj+cHGThdhjan9CdHRztoa9LIVqsycrhQz51nN5RvJalt9Mtzpi4/6l+dJD4Q
YslGVOztxHKVJbQoozEMvBn37atewiOw6DQS53Iask7ak6ThNZw09ml1RUYuvyC/0Nx5yfP99LdI
mzp9ev/RnS2DUxvENhf427CACtEZ1MjeuvLOqU5Do9bFQsep0ogPekOa1k9ncwFNfjrkQkJiSnYu
noIZZz6a/s2iHNKfId5XYxXUXwD9DX3ljB5MoRVJLuUJFYkViWWJtTGwl0lJUik4m85XkgeJmidQ
+kNyfkg3Y6uP9YzW2nj+SuFLf1kJ655n/s+ejj+O+vlJLsr6IxyqI8z6OPQ8Fszy9YhK5ZKvbqlZ
DzPA1z09mvn9j3Y3ei/1F+/Y+h9p9nvGku4mkXeihd9Fst3VD4Q8N/QsWwP7EtI1mrRMDl99HGAX
jtoX0sEqEnvltth7nnx0cGt4GTm9TFXcIf7koWUSvYK3Yx/bYSOhpDmh5cF95G5G7K2SGsEjIlJf
CJGE72NL8w5ndlqZce0v5cU5eiURcGWWOHCvr2IbCQHe5dKSTIOa5F4mHTKSxfg4TTJUxT59/j4D
V1J+8OQt8kTd5FuYVBmi84VACNZsk/klRQZIt8N62HBE3q/XFBDvZMx1Va0dUaWJyRGZu+d8OBvR
yOnhN2gsYhZ8j+13+qSGBVlvzrt0o2nWVnQxozVmIXLhv2HBNcTXz5+IlgrUTFZhrqHs1g1k3xfX
6xMeHxsZWRvT3lRYXFDAoYAJ/9+hVjRq+b6bBAi0mdimnn/IFhYTBOsYbBTFglQbq/PK1xSqKhip
KAyHEJ/TlRe/W7av2PABaXkGhYqmYA6LsFscngtLXTLBt7sbjpVwPTSgKQ3Ivrd/mLpIiILIbb5A
QiHy40ezbdF1srD4aFlYU7y5ra7JzOGBkf/0PzKRd6lFK60wbCEYbPkdGAxDSHZdRS423wbhFj6R
hXsHjnd1Ggwk7eqYwqwCZdr8pdj+9QbvbktdY0tLgik0OisjN3cYwn85tLWh3mJKbg6yDSWPIFhf
+6NnjeD7fiG6jfXsvhIoyddo00vF+A+IDUObAM0CdASNRs+ePF5WqtWCgTHkGTNTd+7IyubwM1gi
w2sBOwCW38Vr0XMvMj+viVRk0YtIz8JXqUi0Edl7fzH7Y2IhmSSz5IG6RCFGEuyyH28APBPwYRJt
ntvhm046BJSMUp9TVHHiZOE+Dj2DJGa0FpADY3MZYs2O35DMbY2MMURQvuXd2QyNEtQa8gGinngC
Eojuf9lxsaUlJ6mRUwdm74kwpdaVtRUeOe3VM98VT/C2vkkZ8Sub/i31QQNoBd1pVPiLcfW/H8kL
aEf0CG3oF5SgdiHqRhvYfty+nrYx6Cf2nP1n8lhzgA2uPn62kA8e2skaSiCf1K00syg9NU+hUHIY
/88Spe0tWHpRZmlFfkmJYZj+5iF7s+DIIKofFPJp6CoLjzL6w9/2+8viuq2Ax4HvS2mykFXq6eAF
6/Qv9Cw5vvL9pNMkSd0uP3G/46p+EPoZLMf9bBi4VyQ8yDgPd4ngvwt/Lj5b+92HRY3QBu+m1Mwu
2QorYA1RkTkKz4TJ7mnh1ncVRN74/ZYuUmTFDSG6POTENqm10dyegO1xbtZ3e00EnjebmMdFROEU
blxouOiI/jYcI587cGQYtlDaTVXSMayUN9G3D+5ZBKcfIPlXQtSOdrMV5Z2WirKL5/vOwucMGj3t
OkmSDktnz/U+lFNW21p+8NROUHDNA5cbe0lE6Vm64PlVy7E9fkqMx+EJigzy9BHrwotFzWgNCa6q
xOydiqTc7OWQSrjhLhpW0QHSXwe/f9MkeP87tOcHISpAd9gbJzZPxk6vBm/fuqLmdKj4QGO9Zb+8
PiJalhLg9t1GJEIuX37x7Sfrrk2tE98w912Bj5iP5px/XrJ48/LgxlRTa01dc0dEWbyW6zx7XV8F
jOla9pTXovzTUsWRUrl6U16SJltD8mJaIUnVNlf7JZNjh8k8NOF3ktnPPct3kzjZFNi8DhgStX8P
s2P/q+x/PKhgkYC+/3nHpZaW7OQGctQcf3lJWkUOqQrtSKR6dTmSFe2rFWH/Ytpif200Zz9yQY3D
KLPBweFahcNTFPUPYd217wplbmRzdHJlYW0KZW5kb2JqCjM5IDAgb2JqCjw8L1R5cGUvRm9udERl
c2NyaXB0b3IvRm9udE5hbWUvR0pEVFNOK0NNUjYvRm9udEJCb3hbMCAtMjEgNTY0IDY3NV0vRmxh
Z3MgNjU1NjgKL0FzY2VudCA2NzUKL0NhcEhlaWdodCA2NzUKL0Rlc2NlbnQgLTIxCi9JdGFsaWNB
bmdsZSAwCi9TdGVtViA4NAovTWlzc2luZ1dpZHRoIDUwMAovQ2hhclNldCgvZm91ci9vbmUvdGhy
ZWUvdHdvKS9Gb250RmlsZTMgNzIgMCBSPj4KZW5kb2JqCjcyIDAgb2JqCjw8L0ZpbHRlci9GbGF0
ZURlY29kZQovU3VidHlwZS9UeXBlMUMvTGVuZ3RoIDY4Nz4+c3RyZWFtCnicHY9rSFNhHMbfs9s5
6sq8DDLr7ECzJnkvnLML5LogopIWCWVtuJObeLa1HTdW6pwk6t5KsrQoZSZNnU6lEQlCFloojSDK
D5kkBlboBwsy3iNHqC0eePg/X37P/8GASAAwDBNristyI4eCS8a43QJujxDaublNlRhKhVAqGt3c
GY+0ceh8LDqzAwgxjLnapDFbnFZjtYGllFWpVLZarUqjcrKy1NRxhrYaq3QmqljHGmhGx4ZDLVVu
rjLSrJNSHjGwrCU/M9PhcGToGFuG2Vp9LDWNchhZA1VG22irndZTp8wmlirRMTQV+SwjYhozY6lj
aStVbNbTVhMAQHQoO+cgADIQDxJAIhCHpwARqARDWDI2zLVt5xAMorggV+HFOLAk5OZQnizIR3El
eD/stDrb21zNJP9zq1KsR6HDeA10qUiTXuK9uXp7Ak7A1Tav54V0b9CEq+D9gHwRz+P2yfi//CD+
H8x5gxNeDPm+ChG/GSvzt0KGLCxKgdWQ0OM++A7ODhJbt8LURgWp1UumOxbgTFgLcLo1QtXiCvgg
II+gvqEfCKwEsY8IoK5fQm4MlcquSNob3IX1TTda8mEDJPhSCUr8PTqwEhr2J/n9z6bgBwLF8eJ5
fhcvy85Nr3je0v1kqHf8cePIZbJ/au7pe0hszBzNP3Gx4GSRnHfzjNvt8cDaJO60JFxpH3+LcCQP
IGzjVQBb+4NcSChEk2hZtvy6LIUXFF4osCjuvLkkD3Y88sEBYtTWX2NhrumUSFCOEpByfW19vvwT
H+MnP/tCIfiFWEyf5aV8VM45tTbg8voGeseG63otHeTky+/wHiSmQra8s7UH9rfInR5LezN0e5o8
sJ643g17yO32Pk7zEJm77vZJeF03HoxeiiGjRSqvNGqkUypd6pFuA+AfaiYpcQplbmRzdHJlYW0K
ZW5kb2JqCjM3IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvV1lTV1BIK0NN
UjcvRm9udEJCb3hbMCAtMjAgNTI5IDY3NF0vRmxhZ3MgNjU1NjgKL0FzY2VudCA2NzQKL0NhcEhl
aWdodCA2NzQKL0Rlc2NlbnQgLTIwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA3OQovTWlzc2luZ1dp
ZHRoIDUwMAovQ2hhclNldCgvZm91ci9vbmUvdGhyZWUvdHdvKS9Gb250RmlsZTMgNzMgMCBSPj4K
ZW5kb2JqCjczIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBlMUMvTGVu
Z3RoIDY4ND4+c3RyZWFtCnicHY9dSFNxAMX/d3fu3mymmQui2q4UqWA6P3BtpRADH9JJGmIFglNv
c7btznltGczPtF3/rgfTFaXMj2w2P66+ZAwkMLBSJAsMJkVSL6MEwbT/letDWy+Hc15+5xwMSCUA
w7AYvaFMEzVnhZOYcEoinMahUxjfz4uBchzKpdP7ikRUdRRVxKPSBIBjmLWhTc/Ymx1mUx1Lpdak
UVlarSadylartdRlK+0w1xhtlMHI1tFWIxsJFuoaU2Om2WYq9VIdy9p1mZlOpzPDaG3MYBymgrR0
ymlm66gyupF23KFrqULGxlIlRitNRZdlREXPWO1NLO2gDEwt7bABAKS5Wdk5AChAIjgGkkBM5AqQ
gkoQwI5jfsF9RFiFPErihZs+DIVDuDCOLih4ERfKiGHY19T6ALraleL3g6oYEwpqCTNs1SntJtmC
Z8XDw1m4wi1wC/IzvJ3QwcfTqm9EvnBOcSARB4n/YOE5Px/h9n3F0c/9BMULrpdRFhWre6ohaSLG
4Cpc9JMHfUQ9bElR0ibZUC+KfzgLAxAlukd6olyaSIFPplRR2Cba2gvz2PIe6tzCBQ+6ojDL3E3t
V1vaO7sKoAuSYrFsNzzjfxdcX1r7AH+RKC55XUwSEzS5mddfdQ+MTQzyQ/dnKpSBzx9HgpDcfpOv
yzUU3japxC6xo70DcpA5IahlkS7n5CeEo2Q/InYWJ7DNHcT8xdE4+qEIvS2nxAT9rdKaHO+SURX0
eKfgMDnZOGphmHvV5/+UoDik+h3eDhWFRMmocndu7gt8T26ol0RcxPPKL5pH7r4M+Eb9E85hi0c5
M7/mnYXk6+WmXKOrssGiqqcZ7obbwXGwu4fkOrk2Vz8cVB1x+gT9U2Qb6PfJRKOX4GM3DitjpRqf
/JD/kVy+8UweB8A/sMQnqQplbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvRm9udERl
c2NyaXB0b3IvRm9udE5hbWUvQlNZWFpHK0NNVFQxMC9Gb250QkJveFstNCAtMjI5IDUyNCA2MjJd
L0ZsYWdzIDMzCi9Bc2NlbnQgNjIyCi9DYXBIZWlnaHQgNjIyCi9EZXNjZW50IC0yMjkKL0l0YWxp
Y0FuZ2xlIDAKL1N0ZW1WIDc4Ci9BdmdXaWR0aCA1MjUKL01heFdpZHRoIDUyNQovTWlzc2luZ1dp
ZHRoIDUyNQovWEhlaWdodCA0NDIKL0NoYXJTZXQoL2EvYXN0ZXJpc2svYi9jL2QvZS9leGNsYW0v
Zi9nL2wvbS9vL3AvcGVyaW9kL3IvdC93L3gveS96KS9Gb250RmlsZTMgNzQgMCBSPj4KZW5kb2Jq
Cjc0IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBlMUMvTGVuZ3RoIDIx
ODQ+PnN0cmVhbQp4nIWVe1QTdxbHJyRMRkURYhSqOxO3FW2x+Ki2arsWxMfWFrUKPqqgASIJJkRC
QhLe8iiSG0A0AuGVRAIBFEXBxyLWR1UCxRoVu+0ee7oqdn1Wd093f+P+PHs2ERU8/aPnzDmZ38zN
3Pv7fj+/ezkEz4vgcDj88IjIyFkzPbdB7EQOO8mL/QO3EOtZ61Mvb/Dhgg+vedJIkT+q9ENKX7Rh
LMHlcJSa/HDldr1KliBVi6bFvS2aNX/+B9NFs2fOnC8KU0hUsjhxkihCrJZKFGK1eyEXrVHGySRq
vWjaR1K1evuCGTO0Wm2IWJESolQlLHx7ukgrU0tFqyUpElWqJF60VJmkFq0QKySiwepCBn/ClYrt
GrVEJYpQxktUSQRBjFNuV6m1Yl2sPi4tXrI1Qa6Y/E4IQawiPifWEFHEemIRsYEIJ74gFhMbiSXE
UmIZ8WciglhBeBGjCF9C6JaA4LkfnuK8ycnxGu9l507nVvGm8NJ4f/Ne6d1Ejibv8YP516lg6hL1
C2sbw9oKnOh7J+e8C9ldXDYByYXIL+QXzMO8kGnYDwvuT0deyOv+A+RPYzGeKwyL+O7uz319V699
s3xmSERoGOP+BFY50QwnuuyMdPo/dKEy1wTBDbQA1QgvXjjTe/3CojnBS5Yv+ZP09kkaB/E6xMdy
9wOFOA/vIwHynf1o8sYYvVzGCB42FZkl9CIyXQVyRQOYmRPPHJuHVug90twAzS0qSGc2k+6s4EQ9
nozoXRdaemuC4ARSoRXCexcfoNG0MaVGawfKZqlutGQfnbf+U/1nkYzg+1Z+S8FeGY29yAwVKOT1
UM3cwD0LhlbITFZ5kiRDBoO55KA8l53/snA8WWa7uEjFkkI0j6yyu6NS3KXgeT+SdWCTSSFVS8+f
w39erx2qmNt4Jxl8OaH/+o1jA7VglSYaUtNoQ8TqHWqgFsJpu0e4QisKcyGuk1PN5nDZaPenm63Q
0pwCegbzSX2Ku6p9UMd0kRvwV94GsrAh6y/ZHfreneVS2AE6yNHszI/DdKGWMpDr0FfeXWRtvbss
Nehe/d0KzUw3HihVl2S0Q2A7lJhqnfbbRnOJjTKSu9a14RGleRVptVABbVBSXWqjnm850olmOR87
/c+5tgygCLedqazXfqFNftJwGCiHzV2iCjLEO3aV5DFIzr8a9RN+a8sUWKSwptdXOUxtRhr2GI2W
YrOxEkxA/fW0fDEj6MRLdmLfDcFvLO1d/k9akNoGPbs7W6gct2cf8EENqfH6hLQYyAMqIrb1SNfN
NjSllHlpM6eRlXFRO1IJEYmmebeT5saXLo0YdM8GjUxY0MdPvBtelPf8TbLbjEY3PO0kGomn4bF4
rnfc0FM0YtDHVJAzN5HvAPb1Vmpe2Od+9ypH3CAIkVaEnMj7FeMZaAEbIETLB6F6DdwyUgupB1vB
YqcFXeION/EThwHPCDI2QoxeJqfwBl4//zenxHOkdE621ck5dovLLvJgMQy4EUO4OshwLMvaWqDP
lwcayC/rcq35dSEoP8D+Wnh6yos9tZDoj/hp6Q4oAkMgFKnmZ6mSIhOKMgxg3LUHKim7vla1PU2f
LG6N63p8AgWUl9KvGkS/C6UMcNmtiCN0JEFB+o4ibT5dkKXbFAbU++FXfj7pQHw00XoEchmjtC6z
Hqh6a01T/5sQg0NX4knvYZ97U5A/Ylof1Qy52uVCHe6uE4WeCq0WYwnUUK0a0NH4LpmYl5fIRPN1
oGk9CFYL3YCK+bgPd6VqDTshLVBmgzqa9SVtZWCBKuoC/9URlGAb/yXDl5+7deilW/89JUyAzHa6
n6y2uxlJhkwmhi0jf+Menk0KupoSY6u3TMSc4OlYgMfeeeffbtO+hqONjiYKbeMt5q+Jmbdw8cqr
Aw+u9F35pmtN5AulJnWjcU7OOReqd+/rI7RGaK2DNkR++giPx6OCp2JfPOZJEBKigM47do+O+ryd
unxGsz4qVwmhEHoq/SZl7Baa+y+euwKnoUdleot6qRbyc3LQZ66Ht7iozNOExgwzeUwn+cO30EwX
muIPWvZVO7o/hPQPF0bPoddOHepIT3BPkAd+hbzBA3j9UKsL8gCO9d0o7Py5bhTd7d90QedCka4j
Fz6/NkHwnxyUiRYLo8SdZ84fP3767NFNa1dv3ryOmSUVlhQdVncB9Y/+awPNuU1pDsZaUV9aaSzb
vi9/L1A1+yqa9ulaonK+MMiimfRyaV00UO8uDn1/S01ilY4RYCInPVejeAOkZpUpOywGlkEONffX
FWgcGvdrz9/b9KfWN9JZu8W2WUAtIfMgC/KKM6AAss05ZoMFiqG02Fy6l0KjcK9wauix47Wm/fst
jL3aBP1ADSBvmLs5dMvUQdzYTLd6OncDP8V+KxycArOHDZfxzzKxcNj6x2Hijh8+bc58jUZ5Ls+I
47BThEXNWtADtW1QWCscYnAPPyH1RYe5PahxKiQwaBlf0DXQ0dmxz5y2nMaZfJ3qRdB3rwX9bsiX
fAsgcrYiNiteSWe0KmsTgRLc2AaKzBTNc1ge/2RlJ7snlvQxF/WxPcIzsaW5ubGFa2W78IziGNoY
C/HFscbkBqiEQ1Cyp7i9+Kyxz3jWeLr0HJyhnlXwHBqbUqnRKJU2jcNhszk8bN+xprLh+G4v8u29
avG/zAZg7aUJgv+hE6hM6JRttVwRN6YXwx6gLJW1VTXZpiIjo6pZdiDZjIiLARW7K3dDHVUKTXE0
Hhte3GC8BE2BJjiQmAiJuUnGT4qTaUz0ZpqKIB8CtVn6DF15QWU+gzirMLEqOz+rALSBhZDUTqOx
14qSDZ9AUmAuJB44AAdMTYZLRQ2eCgH5cdAm5MdFP/QI2xQN2yQquXxrc/L+w/aWFnpMTjkbbkIf
l5NYv5vvHOkaRY/k6ZU+I5w+Pi6f0QTxf3Mr6TwKZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iago8
PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1lBR0xRRCtDTVRJMTAvRm9udEJCb3hbMCAt
MTk0IDg0MiA2OTRdL0ZsYWdzIDQKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2OTQKL0Rlc2NlbnQg
LTE5NAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTI2Ci9NaXNzaW5nV2lkdGggNTAwCi9YSGVpZ2h0
IDQ0MgovQ2hhclNldCgvYS9iL2MvZC9lL2gvaHlwaGVuL2kvay9sL20vbi9vL3AvcXVvdGVyaWdo
dC9yL3MvdC91L3YpL0ZvbnRGaWxlMyA3NSAwIFI+PgplbmRvYmoKNzUgMCBvYmoKPDwvRmlsdGVy
L0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMjI3OD4+c3RyZWFtCnicrVZ7UFN3
Fr4xCBdl2Va828navTdtHQutWuy6WmvX1lLs+kDEqoh1gQARQiSJIUAkEhISQpJDIA8SEh558AgQ
UEErjwLiC8rWjmjbsR21St3tTOvszG53t/sLve7MXh6uduwf2u3cP3Lzxz3zne/7zjkfCwuZh7FY
rLC4hF2bV8VOvy4LLmEFn54X/A0b6D1TN6e2zIcINkSEdDwdEb8IOZ9E4l+ilCcwNoslLtDGiSWH
pYLsHBk3OjOGu2rdurXLuS/Hxq7jbszjSwWZPBE3gSfL4efxZMyfg9x3xJkCvuwwN/q1HJlM8upL
LxUVFa3k5eWvFEuzN8Qs5xYJZDncnfx8vrSQn8XdJBbJuNt5eXzuLLqVsz9x4jxJgYwv5SaIs/hS
EYZhi0ViiTRfVlDIy8jM4ucIhAfznl+BYYnYDiwJewfbhe3G9mDJ2JtYHPYWFo9twjZjW7BtWAK2
HcOxSIxgKMBCsF5WBOvcvA3zzrB/x54MSQmh5xvm/zW0JSwi7ByeHB4b3rTAueDGwqigPjI4pvIF
V/hYKHscJYyzUTGKI8w+i9fsc56GyoZ2V3P/1c8A7zOlFiak0QtLMimlQF8GhXhaW/bg10dRjNmu
Aa0SDEcqSI1EEpMEeKGxztVib7U1U54z76EQGMW/2OXbt+7dRLmS1A4JOtIhG4pkijx5pnIHGHC1
HczOykqfmWy84h4KAN4KIpVCL69QUG/QZwzlRh3oOSrbEU9tg9VtJSODtjnE866g2ivsoAUFiDs7
Lq+mn6AJ+ll62dIPE26iJxCBnkXPk7SF9hBZBwKfDLcidudZqnt8sOME4ENtaTvSC5YKEynRrr2p
+wBnqtJ7Amj5TOVg4iX2V/RiQnNQo88y4mWlINeadVbKD+1VbdAJR/UBGI54zuIEd60aSvaCxW6x
tlbXU8fRMmtxS8YIcBALLUTRKObfiUOJ+9KzBSKqdDS1VvoInZeDQiumxmSE7eifrp0DvN++U8iT
0AtFW6lSaXr8XsCT1JO2qsoqk42KDK5TedHla3UM5phbbORA7xGVVf2I+BLM0AaekhyVXgg6XFkj
b20MuE6MbHHkbspOKVCQqjNZ7tyfqEOHtd1mYnRYrvJduI5WTgz7Fn02qT2PFl3Y/+lTUd8jQClE
n7pfDbtxoWT90oIk82kFedoMp8CEu5XOQpm4OHX7aPbH6IUeFDlw+/eNGTVk1HdiS7at99fN3onr
/m51loMUVmgkoMZVluLmhtba3oGME5vp8IwXk8mo72HDRyVt5XgkmmScwAmgOA/D9gds5AwuJSZD
GxyMLGWgoNaHdqPoaheYwMzxFpvVUnUhY9Is+rfz14QWq0BeWgP11PXQOPqksaJCASWclK7Mkb+f
nrN0KRgPa8jD72a+sRNwCbTUW6He2sZQ3jVnv5fG0apxdtAeXEKYLJVmqMIdmrqiPK1IYyDfpPt1
h8FQpuTIxaK8NMBTy/q6xru+apmgbF6zC9z4cG4gfWUOHV0+S7vJVU3aAv47o4A7HPpD+WpJSRZ1
KP7QRkjGV4+Kzp452tHRTDbu7i13Qzd4W+oCjT21owyhM1CNxoJysuQd+TYB4IfA77oHNX0Oauy4
6zxaNcQOqoMRxLHSgEgmlcmUVq1FSzYfqhIy0yzeT1fTYbtVw12jnbf9n5DmekvdI6I8uKYoEfbj
sRdFY+i1AfSf1rkRXeIx+BYhbAK9Pv5U1Ofo2zHCsa+78Ngjw59ALQ+IJ9QKdEYyqr9XLqwXLqHZ
9AJ6Ob1szUD8VSrq8+PQ5z05hJ9FVmI/naQRJry6Czj7NWMdwwEU3niKahkfGH6PWWItyTyDUWco
/x816MApFgq7gCSX2Oj81CpieqoYVDXlVRq92mjUk9GaUqPKCHKOyg6uQZNWrdcrwUhG36WMenUG
8DlrT739KQpB4egF9Pz0sPMFhUIBqb8bSUhzvVf7ao61o1DK2gymOk/7yZ6jPT820DNoUM+1/tml
xptkB98O/oJIKYcMZi4VDkWTv9nXM5TevfXejose2/xntPjm3+rMGoemwmhUa8iNK16uKAZ8t7R/
9Iz/X62D1PGPho/1gwP6DXUZ+L2tOdPwjCbs4NnHaDiJVh4JSPw84DxI/fE+79BJ6tFlrbM0Uzua
mb26ff0uwB8SyAZNxkaxXWEXgRz0xgpD+Rw1Eh9az3ATehnpethIgxREB1yqGnRf64SPwIoPHDix
9Vn6uWV0/KrBNXd+nJctqo9P9Nj7rX7K4iN60Sv/qLIDfrJJIniGXge51A/4mTzfOP54fqCj7942
GoxlYOCoao64vc4GRxVZXdeJfmVtm72mNccrTY2dns7eD6/8HNf0Dzk5eQfJSDR7vRHnxiK0+Pz7
53hfPBUVRLfQc8QDdUSSF5k6mpJKf6uzy9lNXUSv29uZvtycc/yWAysEdIzu/njXdLV+PTPeOlm+
SqSVU3mvKHNLmYdTwq9QQRGe1Zwx8k0XeqGajPqLLigjWopsJYWSIrHUo3F52tzt5KxkIv+VG85Z
Ot+/ODb5f9HZYW2rMZGnUVq37mIhJHFACxX6EkZVLXMg4t6Xdvf5utwO0tfjGme28H3vKffK32Z2
r8TQ5GmytlWaKbMXKsEJE/H+bTVNLq/XHxgZOzEwDG6wqiqNPK0uBzQzx9LX1tjTevho6p50XqaA
3LlZocgpZu4N45Ep4hTrmw8es50n7zJu1hXBEc6e4wcGezz+FifZcMx1cQ6trhx0elIrLY6X88TA
uT8rkVOj99PZ9nG054cBbQhMtd724d7Ry4APwN4jEq3IUEZtoZ0PhaaTaPXsN5yHPvrpPryV5Nkf
n5KWlkdqLie7UyER9uUK/vgzJDw0FqS8hWjkme+YkI7m5zdPm/rb4D8JVSL/rc27lYy6UIHrq7RW
NxP0FqJwr+5UeqY0RyRsUnsbGmvsdqbGFEo8z/oSWdjoAkok3Ewgqqo1WSw+qMan0wFJJ4cWgQEq
lIZynXw6I9mgkYws8AXjHCjfVO8LpXmOsMCCiYXkgpC1nohwX01EBIb9Fy0PEJUKZW5kc3RyZWFt
CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NaSlZGWCtD
TUJYMTAvRm9udEJCb3hbMCAtMjUwIDkzNSA3NTBdL0ZsYWdzIDQKL0FzY2VudCA3NTAKL0NhcEhl
aWdodCA3NTAKL0Rlc2NlbnQgLTI1MAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQwCi9NaXNzaW5n
V2lkdGggNTAwCi9DaGFyU2V0KC9CL0MvRC9JL0wvTi9PL1AvUi9TL1QvYS9iL2MvZC9lL2ZmbC9m
b3VyL2cvaC9oeXBoZW4vaS9rL2wvbS9uL28vb25lL3AvcGVyaW9kL3Ivcy9zbGFzaC90L3RocmVl
L3R3by91L3Yvdy95L3opL0ZvbnRGaWxlMyA3NiAwIFI+PgplbmRvYmoKNzYgMCBvYmoKPDwvRmls
dGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggNDE3MT4+c3RyZWFtCnicpVcJ
VBTXtq22oapUBKVTQTSpxnlEcXp5mjgEBZznAbVFmRRE5hlltqG7T3czIzgwiaggdJihRY1z1MQX
h290JT+JQ8anL4bEnMJL3v+3QU3yV7L+X+uvWlANdbvOuWfvfc6+MsaqDyOTybj5y1w9p7hYPo6W
hsqkN/pIb8qBGJ+/3ZVmDTZysLFqeENx3h4/GYR77XDjQEYuk4VG750fGhYfEbgjIMpprO84pykz
Z7410Wmqi8tMp3eD/SMCfb1DnJZ5RwX4B3tH0T92Oa0J9Q30j4p3GvtOQFRU2KzJk2NjYyd5B0dO
Co3YMWfcRKfYwKgAp9X+kf4RMf5+Tu6hIVFOy72D/Z16s5vUe5sfGhwWHeUf4bQs1M8/IoRhmHEh
rqHzwxZEREZFL4qJ9fZZGu+b4Lfcf8XKHQGrA9esDdoVPN150uQpU6fZMcwKZgSzkhnJrGJGMWuY
tcw6Zj0zntnAeDKuzHzGmdnELGA2M27MZMadcWGmMAuZRcw0ZjEznZnBLGWWMcsZgbFl7JiBjD2j
YF6T2TDjaQUZKyaW6ZQtlV3rs7xPldxG3iJ/bqWyKrG2sq5ip7M17L+4UO4f/HC+rO/bfSv7DeoX
3n9h/0YbL5uGAX4D2myX2abZjbPbY5djV2/3/cDpA48OWmo/VtLYdtmDGZ+e22GyR5Ze25B1ULTR
D5JArriruKP6y4Z6aIBL2qO6UzYjzO7oz6HsfsfV2rKYuSKp+NMl+7if1zWMmbB+tWe4qLiLDEfm
pVurOEXblVzwU9p2XaIh20x40GyPY9ABz+JwwuEYB4WE1VJ/AQ/iYu7poXe2zNm8bLwS2QQBmZIP
L8Nd/pvpn5IZYre7CpnuR6ziZ8KoJD8WZ33x8Mk/Z1wn/fOVM8g1gSzFNlzPloIZared8IY1kMIn
A3mNjBRtpVvqRklhktXga5iLr8mlBgwRcMjkp+Qt8neXUcSRDHw4Bt/Gdx48RTuR5JGlAlEAMg/a
4PTBWmXJe81lHdAMzbvLA8oCYS1s5qcDYYhCtO26mWKWnptl19BZ0nTIu3K7pgglkB+fptXuTRcX
rVx2auEhD3AkBuJMxhFv4o30jgZcgdZoh1zpXn1CUhok6JR7yRAyYPlomA1vHd7wgepC8h34Cs4b
kbn60YcfPSg8Q7OB7+eWE4UxTq+tAP6I3nCE1tSerDfjMJMkO+fbaP+MApiNrzkoPsMw/E8BSvT6
4uLGpjM55cBfP7+c2JNhbhsWJ6rgrJcypQj0UMLPtmoJaE1tAh7H//gVKtHR5Tsyct76XfFRSsXj
Do64WRCk+Pkru/V/Bjpn+9wazNIjs4xi+obkgGPkOKZLIXQ/sqA0n8ONOJ5udCeGkfEokE3KblcV
i5ruR4L0CEdzH8HncR1udZ55HjAJiCx5fZDXZo9pu5cDbysFU7oU4Yi15+i+mGdoayHoVvxKQGuO
zHqRlp+yh651+jZDO9TDNTBpLGlNx/mc4u6NSrT9QdTp4ndDCO9TE3vsWE1Z4/vrjm0QFW1u4Lsx
aimNslFtkobW2Nc3e9/EZPrLgTJ3B5qF7bmLC8HMX/kWSu7Uh6zNFvV79BllwB+G7Arlp5wF40wt
xPmJ4UUBOb7ABxO6AQff0rDSBGVjQL36biKveGRS30laOWTeZIgeFn67JVnMKM6AROAjQR2lJDIu
DtIO5Rpgf5moh/L9RkN70BkoBb4aJwGObomtCziqVNz1OxaUM7uIZrpG3Yj/Zca5pbJOinM/s7xT
GiaQKs7pQfTNT9ou3BbfV3lyHkGRoavgWoWIx3C0mYzGNSpON2bT2LEafgdH6aI27Xif6v53qo+T
Ft8SZnPolmNt5pbthQalok2i2l3yW4nXcDM917vO0VSeFfG7PzxJ5Jw+i/6XqIg7Areg/R7NcuEr
NgyXYzNlArJm1kczDrbQaxz4GCk+KmQpP1gV12R8Au30egJNPbgRlrOVOjPLpIFm2RHptFwySjZC
TnFW7jXgzVyENkQXARHgZYjRW97ClRzTpOt02sw0JeGJkSjwiPVZM7tTO0Wng1C6zKdn2TUO53fb
7IsogiJwPAgFxoIynuq2N0plV5m8K5pGyS7KyrtkiRKlDdZFQhioDNG9UfI7dCkajVqnUQ4n+YTF
E9bnzWyQboM2GLzB27C7Z9UlrmwjaEEHmZaV75C1g4djoWWhj9ZH5wO7YKsh8MVCdO7ul5uQlVoJ
jpWQVZB78BnuG/yM7PvD/2glz6tNwWZccRydTfY12HcODsLpFsBipH53hV2w5SfxJFu6Dw5XJEGS
crme7q6CxyDu0YIPybjVxDZz2ta6uKrqmrLm43EHNQbxaE6Nfh/wd+q85yoDOYV5gYbkppFRQybg
wPiPRUXMp2BuKm/mE3CKMJGbMDkpwtO3rhUZnFp8yij2MCe4THrThKvO/dZn9uBOaZSA7b/1CT9l
92Mz13HeWtGRntex7tFQHNfZ01ecvyOjlIo9rrAxJDKWzyHnBMziqupOHjtHe48tkAFuKlgb7qcM
8dmSEgRu4Hc2dT+FyeM3OuFls7zLAasEFZvunkCmEg/gR9IuMtTMbtUQGWyCrTAa/HsJxvQ2oBsW
PhGVSbpolpUj10uo3GJjL6EiKdR/IJShDZJ1mak6nZJwREcJVfEXhFrRPSxqc/TmII8F4JgIWn26
MT+rohjq+BORhwNDQ+L8PM0+l+9evHKhig6fPDp87Bpl9XT4uOIgOXZLE4T43doYSONfQnSf8Dmr
iMe7NCxPHL+biJPwb8eRzy1OhNR4nTYpQwxfujnOE3iiBBzTfh7wdRTqDmo0RUr6fmiUrOhwk1zl
0jqKR16hwQD5fFkixIvdcjaZzLc2szmd1aZO4L9kSU03k5ZCuZrmGF0EJaI0kD2EXtYqNm307uVk
MPAz2F60zZK8B21L3tkW4u2R/tYibOJwyatOIf38e+TJBk7R0bBxQ87OoWT08GlkGBn8zUQcS1H/
AE4erq7k8aoVMXJJ8T5r59Kd2AIOuHESzh5pUB5rNhdUwwVoDCoP4W2fD34J+vtS5vtyPNs1Q0jZ
p9PH0C/FW6C9zEK0TheqidRoKSx8hIqtN16gU6kZzrxoJBFcPCTo4w0hRh1trbxUykkZ3Z8XJOt1
B8CxCvIrlNIdDsr1+qPGw0YDHAW+0sz6a1aDH9X0hhddqpI7BAd1h7THNHodRPPd4yiZDtMmvPQE
zur1EunfyyUfaiXKC6CqWn174ynldtP6Q+40z+nTR5JBZMgP43EGTm15dvBQHGQkaDN2q5Uxm1cH
LaYrhunQ8bTyhJWhQd9cduJIY+O+Y4B9wUAc9AGU+D+lNHWxTT2+4l10lnc14jcC7iKjqGmKIPFE
ScaS7cQXncgIjMUEFHEUeovdVuQDYSW4HvX5ZOeV9JtwH64Zv2z9R9MH1ysv0eH4cWjjovolWXPA
A9wyp3q7e7m6Ra+jo7ario7avCbseCG0GhoQm5FK1I2l2uVvYV/sM/ZLMkvZPeOltGjJn0ALvZ5A
fW/vZjhakQ6BDMEOHMrieJg7fwHMIRMoQ2+RLSac+M+bJoxqsq/5zg3luADl8NDtvoPilxTMw9XC
NLje1gbXHz6EhV5esHCaktimCu2Rp7WVtD+MPHfvhjnixJ4DyuMHygyFem2GNg3UfMTB+CNHDpYc
rkio27JHpQnYKsbv8y57lxZ35NrZbj6lPjXUxXQxoQHqnTFDYE/WpsagJI1rDCzlPc/NQxW63bt0
43j61YW14pqjK2AChNMRlaHfmptSD4egIGt/Th5/hawTsC9bjdawbIffOvI6sdnU3n75KhQrezx0
r0ZkL8epnE47wV3F/n/8s+cq3ygRv/+9smy7OlNMEWasNmF1j3t+A9NwvBM6f33KQbEbTfirgNXY
j8MZhtnL18DfyUwlTogRkD9++kP4iH9K+nxBVordA1+BZ6LgUT9LwTO9AA+rOcUputNiaIXqwJoA
iANXWASbbgS2Rl/JpAbxl6KvDpTTdhSjS03SKTNUIdHBsALSbmY0awvTP9ZlJ95YW73tAG+Lt3pO
Fo/Qxf4eupB+yDgovsUoab1AXC0buvTKtVXrOwzNcBxOa009FVjGKZ4WSNeF1h213tsCArZtqwto
aTbVtlqmD3XZ/26xv9bm9Rg/fjynzUFxWxotTRXIqGrf/DW18IFjy9ErP3z6NJC8USFmRYL2pVPD
JT1WjdqE1BTRa+uq9sX5m6kdnzh/wvDFJ7aURSs7NtXuRVkkr/j2IR2T5TH791RSGvCbw91HzCUT
S3Fcuqg7BNnRL13b4h7Xlm8w5OaJ7e0fbfpW3QSOOPMKWj9VKm4Dymd95lJCJdVEuXHvoqzZjHup
otLp6Irqekv4dQYbQ9S0HeejdcFnOBL4u933iLOKPWukerhEL3o72wuJs3TvEw5HQMHbBYTlzSyd
ZLSynWbccE5GHbGcmupUQdryh9l7ipb1Pb3ZYIL34OSLsrqjgjtWkZdTWvyU2A/OTz4QCxo+LR6S
RBV33PBAnw0mqNXVai1rE7htoMlKOkBm447B+PrT4sL83OvgaObCNBFUHmGw2BDVOyorwKjJS++F
W3pEFcBbUorqWiz8z3xq9CcNlkbRrq19dWZY/YfTp3fvj4Oi4387gT7ouFJbHjvnrxT0f1iyj+v0
bBrpsmHjlnAx9tvJRn+YDqu9gpby9ND06sTa0as6yUJlmVlyK5XhbTq5pVXoIjw2j5dmslXa7NAY
nW5Pskh+7F5krcImIiNWKq7e+DXdaiM8gLoeFMdz1DG6CARYBLxqbSsp0PWxrAgvyvEmugqPycXx
nKWG6CL7DF3kmHpPaAmo2/aS/i11dS2W4ysxlj1fUyq7Jq2WS4aulUL2PsgBPV+6uzAxJiMxUS12
2/17UkYyqEHnGHsgpbgsu2h/jtizAUltbqX5J2N/Of7SJRfKoSA8RQt708Q5q0cCnamxqlL2AJzT
Xyrhu4uJUsW1Gp9BB72eQWsvE504y5uo/7yAw+rNsgs4Et1RlEvFGEHNmCY2bUni3hT1PNhNO+8Y
1txwpqXtBLJfXDPD9zxyI/6DOoEBzsumrDy553BNY/mpM94H9mSJxw7XF5qAv9/uMc/d38NtgZJs
Id5JydSYxDrGS+9aQqa00EmE1g238M36BvuT9Og8gI4jEd+kd2cHBW1aP+PPwsdlty/Aff7u3Cs0
Tv/ZS97eVh1W31ZZ897FdYWZerHuaGteNfCfG5fsTNIRhxFqpY9Wq8vQpeq0qXSGKLpT4gvgkNjK
ogzGeapg1IjwDVnHNytP5FdWQhPfFlS91TsgzHPK4xUooMftH74WaWA4F3Kf9h6+l8lUk2Emiybp
yZHB7VQIXd9QIaTp1mZmwl56KFAbgvLDaUddD3PUywK9GpdCLC2VDRm9nfRXjpmnukM6/0wo2Ik7
/vLJ9j9/wv3qQI+FTzjk0Ca3vrpcnVkoZmgiEiAQEnOiSpL4YdyPrz/hfnp86Gp5lUarA51WK6Ym
qxMpeslZMQeSsjMpBLv50ZxtSqG0Mh+9ygoKWbIllzP3Q7a/2M/qrVKbvo25NjbIHrUZoLexZZj/
Bsixw7kKZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv
bnROYW1lL0JDQ1JJUytDTVIxMC9Gb250QkJveFstNDAgLTI1MCAxMDA5IDc1MF0vRmxhZ3MgNAov
QXNjZW50IDc1MAovQ2FwSGVpZ2h0IDc1MAovRGVzY2VudCAtMjUwCi9JdGFsaWNBbmdsZSAwCi9T
dGVtViAxNTEKL01pc3NpbmdXaWR0aCA1MDAKL0NoYXJTZXQoL0EvQi9DL0QvRS9GL0gvSS9LL0wv
TS9OL08vUC9SL1MvVC9VL1cvYS9iL2MvY29sb24vY29tbWEvZC9lL2VpZ2h0L2VuZGFzaC9mL2Zm
L2ZmaS9mZmwvZmkvZml2ZS9mb3VyL2cvaC9oeXBoZW4vaS9qL2svbC9tL24vby9vbmUvcC9wYXJl
bmxlZnQvcGFyZW5yaWdodC9wZXJpb2QvcS9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9xdW90
ZXJpZ2h0L3Ivcy9zZW1pY29sb24vc2V2ZW4vc2l4L3NsYXNoL3QvdGhyZWUvdHdvL3Uvdi93L3gv
eS96L3plcm8pL0ZvbnRGaWxlMyA3NyAwIFI+PgplbmRvYmoKNzcgMCBvYmoKPDwvRmlsdGVyL0Zs
YXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggNzAyMz4+c3RyZWFtCnictVkHdFNXtn1C
WO+FYoLFCzaQJ0MIHQIBQkgg9F5MrwbjbtybcLflIqscSe69yLIl28jGNsUUBzAECC0kQIDQCYQ2
CYGEwNxnrjPzrySbZNZkfubPmr9YSwvb7757zzn77L3PlYDq2oUSCASiWUtWjBtr+d8Qvr+AH9CF
f1voiXWv5G0pdtBDCD267hgw+EsHfmRvVN4LrXmTEgoEwREps0JCY8K3+vpFOg/zHO48bvLkSaOc
3x87drLzjCDv8K2e7sHOS9wj/byD3CPJD4HOK0M8t3pHxjgPm+IXGRn60XvvRUVFjXEPihgTEu77
yfBRzlFbI/2cV3hHeIdv8/ZynhsSHOm81D3I29l6uDHWz1khQaHSSO9w5yUhXt7hwRRFzZ0RPDNk
VujssDnhcyMi50sXbItyXxTtsTjGc0ms11JvF59lvn4rtq70XxWwOjBo7YSJgz6Y9OFHHw91HTa8
x6jRcWPeGzvu/fHd7XtR1CDKhXqHWkYNppZT71IrqCHUSmootYpaTQ2n1lAjqLXUOmomNYpaT82i
RlMbqNnUGGojNYd6j5pLjaXmUeOo+dQCajy1kJpALaImUoupD6gl1FLqQ4ql3qKiqL6UI+VE9acG
UAy1lXqD6kYFUT0peyqE6kW9SfWmHCgx1UfQTdBd0IOaR6pCdaU0gn6CYsHfusQJewqlQr5rUNc7
dsvs/i6aI/qeXkSXMyxz4Y3QbkO6Peoe1v1MD/cep3p69jxov9D+cq/pvXJ6/fqmf+/VvW84FDn8
Iq7v06tPKvsuW8neeau2r0/fI45hjq+c1E7P+sX0a+xv339j/wcDpg8ofnv225q3DW/vffsS15NT
cZckCyTfOzcNbBhk4pX2bSlgRuvN/AK9oK5thpAf1LaYTS9UZcdBHCjl6QnYs/17x5h1nvGr1Uwg
XanZq20EM7Sq6tSHerxjpteHG006TZ5GKzmA+tohEB3BozUKrRwUTkErIZQLpBt1F2An7IUD6maV
ZUkM7QIJ2bJ6Bhv4PBbZ4Wt2WCqy51vBzNs1Sw0OqMt55H2+r3g/6oKesLiC3iyD+eRFDZrD2mow
kb132PaeL4P9ErSY/uXisbNn8lev4HDCv3x2LYSDejuDVtJwF8yBjQml/vrlMBNct4QsYcRXX9B4
oMwukBbvv5CTtkFi37aOZOWcAe0yOyDJbXTiycxnfcU8Cue7sEhN12uzWzj0puhJwwdrFm2YhIWS
hynsk/LzZ+Eyc++9W/gtrr1LYJXoqlbmK2mvosUvfFWyT7iIQH6ACDk9uP+Xe5OvYGGBZAm+zuLe
IldVdr0EmdAy+mnzmPmz104eLLHnlTIjP9YgqLmNtt8W8gHIn0V9hr7EPXHvEViAe2P2l5HoDdTz
px+RmMNh2JXdAm4VoQfC98EpaIRdcLRqX/WBlordsA/2Sk1bTFtgOXiDL6yWukk3uwWvB8a+zUdq
bhttdjj2nA9oCDf2FT8+hr5nsSf6AI9DS9GkH5EEMXmQnSgDebKaS8XvOE/GAmCW4nU70GGJ+CfU
itbuOIUE98fiIXpOmwDKImBKQFchQcl0KWTLFApISuXWz/BpXHdoJDiJH2MXPBGPx1tIgK14jRmN
MvBOzeFGh5fnUcntvuInaDrfgz1H48GWWlzMlrtJxDfb/TqLukPTqjVBNRxWNfweAFPoXDozrnn1
N8Cg7r/8iFgkHvEUd5WIn0wFd7coKaPDxSyKoGsPH6w9DMylU+OxHe45Z9IMT2/9nlBJQgVoQE/S
kQHmNoFZgLi7vPiZsKFtGhtYRXfWsLOCXURoCuLQMLQMrcD90Tg8TYL7/OrMWovI77RB45noNJyX
Hp69d1nuRJgKWBjt4rshKnTF8iEk7XxVR+QjjFF6hx23UQnB+k3+zVMsnve/R8ofl9LeY+3ET2oS
Pc583B8zg0bgt3DvJ0MQQ/J0AfbsNdQyOhTI4oE0BMSESCMSEwJCXYGZufQ+olH3C7cv32iesIag
ewpB90kzqt8hQAPuow1GNNKoMwrRgGtsZ5yXRc0o3y5cFI7HRM7E04HBTh1A1T+gn+QHfCAxorJw
0URZ4AhuHEoT2VqCFaHRUL2qBEsYoygESe3aT3b2gT3fv7PBX557ebev+Cr6GH3Loi40lliqbe07
8f7f2n2XpkVbA7uhBXYrLTnYRs9Q5TdK0BjSJve/ydaCWssp1VFJEMaEVMQbyowFdXWBtVs48dWZ
4Ds/YQupqDMJs8WMDtjCXGVE7xiF/PW2KWz7gdftWdFZWlGD7hppnD3wEBqtG/rTo6CwQYLUd+kf
8joDnpTsP5KbiLI6Au4hQiPAuLIEcyRge56TGfgPyh3qjeGfohhj5Kd9xfeRF1rDGhS34mAWs87P
c+ok3+PfRnPKQnVGMjCJkBYjwY50LKTlZ2o05eWcVgvasvJ97vvVFQTO9IEvvz4StD2pQOJf55Xj
nkOYamX+/MIT/RpMe+6iLpnjArWcJiUXtMAUQma55Cdr26WrICmRUyqSUxRK7xoPiCfVs/eev9Kv
JKRaKhHfrwurkX+dQJDoKDOioXoUYkYf6gW/nEf9CAZm8INZ9I4Zv4MWh4vUk4OchysY6be4lsa9
Hic1Xqy5eJY7Hr6KJl7AZz48LOVsAnLajHaYrVluvS/k2/if2UZt/lWuyizyU84gxOMN08FPR7La
2VI4EbeiRPpPnvqt8Uh1LhMZ2QlXoMFanQj6EyscilErLv6zpwjdyAzSZgK/1+oSzfe/zo6j0eB8
OzM9JzX7IAEfQjQe+hqMeC49YeO8mZMULa0c+rbjL9dA+b4Ej6Cnwlg0ihNHH4N9NbWnGXv0awd7
DLgvRFJL/Lr865zJEtkUEpcXTOmIzERf13VEppRN4cIsZ75OTrwLrnecOYyeorSeuUpWwfczC8r5
BCE/Ad1lcytL957TMGY6UhWsjoQI2KSN1VjeSTep8yMhGlJUCoXsXZzjiLuiOnkhgYXWybQLyjgz
HaReqYqEUPDUBGmtS85AhrwwEA3GyDErQZteCIWQkZuRZ5EF27ZlFjfwd3SfLTtkLmywbCsl20oh
GDZro23bNqoNMeRnOajSE8fiXMdhqE5RoNZCplP1LtCTXYPV61QREATBnbs2QYkqLzFTnh+UHT0R
pzuOQvr0AnLOjM4VtnMqYI3G17biEBQoCwKQA/6rY2aCLtVyTm1WZtFPqNHxZ9yUIbP8yqkQdNaz
E9k0xJpRgMH0YNyjAwaH5qsbH6FJ5y8RcQs6gu5+w2Z4Vru3AFNxquim5Fj4Snp5uFzmr9ifySFX
Gpphl2+T1671JRuBmTzXdUGQPtZUU6Y3FaTXb9JIqhsO5tcBc/C41/sSH1q898g65Rzl4qDpW8PX
ghvz0ZPwMxzZ5Bwc2F3ewqShD9mh9KhZWzdv8Gg49FnzbTQ5i7RK2W8g4Qfzk1g0H83IyTly+KbG
yUyHKQNIgXxhBWy1IoXerc6KhBSIS05OTcPncKsjuvhfaJhZNGKIs1qAK7JSchMhySnIC6Islsnq
0xpgZ4dPo1fDtoygfRbBshC3WVDAa4RoN0pit+/cebDKZG7cU9xigUWYKkgdRoq8Rptog0WFKieR
uMe45MR0+ZKpjlN/SskjJc5yguLiXL11hXqBKg62gasm1FbkC6BRt7g8xazjaNx94/Jlqm3gFEib
tGaNCWqhWVVlU0GpLq0QisFQW3/q62+GOubICuMI+FJS4kMt3nS75pjWQERzl3p7ZwAx2shaxtr8
BNPvGJBPc6fViCdWoyeLLnR4DWvDtz820hpNTlF1CyM+GFncvP5y/05DMfwpFknE8VNhi2tcDDEU
JSzyoKEcNPklu459llMF+6ExrMrb5KFbAR7go3IJ3rwt0Nt/NWwG36qIJuIxdFBGesuOcKWnnuds
XPmtRY5QPhsukr2bQEzdbII7m8ry2+kdUPQ9V28W+SrHkld6ER/xLyrNl4kspsLdUHaHlxK6uCPk
x5O2NZ05rCmB12wRA65aqa0+ZnVJLLHDyWpVetIQrHbEQmRQ5KkySBeamqCcsxUo9vds8SmJtcgP
jWgXOKYnJvjLE6WrQuYugnQgtFNmzsgxQAljii6JjJImBm1u9j10Zs/x41WcPb+MKEz9oyajxees
fZRgtJjoN1Awiybdaj6Se0bt28B5KOVBkMiElUXVmPSl27+atusT3Ps9TOE3OfEL3OfpMALXfnWo
R15eMigJw8lVXPCYhUk+wIj5NeP3ookS+1fDOvrKuYavuilE8rbhbIpBSQ7H4KmvlV5Jh4LrYOtw
cFBbD/VwsNNdDYaWagnfqKGR/NcumYmZBK9O+aDLychH6raejpr2i6LOrmrSfUWoehd8CU2/7yq+
qrMz8VRRGIA6LQaHtJ90JBkAI9/HIGg2otOk2v34d9ncfAvhMYWpEMPhSyIZnmhnFGX9XN6EuhDJ
F4lwXXvPFBmoIN0pIZuUA90WlSIX4sVScLdtbpghQXUTdSqakxXUHS4ynn/zM3YBjYb+pmkH+V9+
D3EcSAc3bjGttrxj0HDMYvGPw5AF2Wdh/w5jHYMqumJ3moBFJYsN2rhZusUCYFPEzrA9yuPEGjVp
T9burzDvrD9KiKI53rw5P5acM4axmgAbs9Xwk2uEKL7tfTalQK2JJht9ElgrKga9ulhdqdSoIZpp
L/+TSpTSmekadYacH9X+xDE3SaPOBqYIsssl/EG6GlqeE4T6qTeo/MEfNmj9bKB+Dq6hkvZptA1z
QRVopsGBTE8p58KtoOuKMtksNPyOcQcwz/Nwfy8JTtnGojqRQQcVT1c/Id3HvDcY95YQzPV7MYLY
Zfv9SFiel6pNT1HJU1Wc3+BxkAzrwXN7ZFPQp3AOGknUZVJT2ySTgExQbs+Fbd7oEYu24JFkgFqI
5+HReAL2wO5oDB6L5qKFaCQajzZz+Fv8HTsS9/sOFaECNOSr2/fQO7NxLi7Db096T2KPTljJFk24
k2MQoK7nHt0Toln8LBYx9HeffrpPVwxpxVySIiYRwpnIkqjq2mJ9VZNP/Zo5H6wZyGF6SuB1fPXP
HPQVJDLTtiFgpwmdsYw891HLcyGKQudZNFWEeiDq5rMfh32H35bgl78bZP9EWpSolEWVthHovgiN
h4EbXIE08njLPIs9KtGKE3cqEVQ61LRGXUEzrzS0up3oK/6rDIWj6ewEeFZZrakrNkpyCiprdgNz
D4ZGhqoD4sMlqUmRIZ4ESIwXCxlQWarfFbJHWQ7M4/PnrzbFNYVXShp3NGaWka7KBJ1apkiXQRIT
W5hUkleeXVmaVOcV5Sb3cOfc6911UmDGzJ37iZvB27hNkhgf4w9+jLiNgsBCb3OUS2zAFvBkZj1d
hexRt18OX2tIOLyuhltTsxyWEr7cAmmagIxtZiBtMhifZ4fMPXzkwM6mfTrJ56K7qCtMXD17/XCJ
7SLD2pYCm9cUoi7fsP9/dxiTwM0l1ptBz3/f5/ZtkVIDqe8RA2o1O5CRFqmR3bTnP5j6il+hSPSS
RQU0VEKBQZenrQU9MA9QVwV+d27ER3iY5Fki+6Tq2im4xvyARXfwUA5/+QcgaNRdtDLhxY5xqdNf
ZCGaFv9aQtxUw9advhAI82EheO7x3uP7mXw7MNdKb9VkQX6iDFLS1BL5bL+YcNgAqYcTHifecIw5
u6F+VTlx09utsyLq+dLhyss55/qKH6M5/FIWO1sC/CJXTojM0JmmOs1RbRWho4bONC1QZO6SiH/K
4HeydeEVIYHS0LBQQ5i5xlhRRxSpVWpuG1vjcMwUdhZ9dXYNScgl9DPvyOI+5iXFXkfhhNOFo6eu
oY8N+MPNWZxGDvL8juEKbbJOV2lqdVIa57ciqNZjz/vghIWTxg/88MjMa6GSfMXhpAuxjPhxddr2
tBqfirA8wlDM7PWzJgVPyzy4hlt+VHlW3ajOSwVl5+jnah39sjXa/GwONDpd/RHz1rO+94kOvHHj
R9RFIr4EzxbcmqQnKTlBFL7kOz7CmhXPR60vFp6zFNPHkpdRlrxczbV4GGd6c8rERemRUBjGFWfo
i6CaMcXoQ0JiosLWHgs5fuX02YdEV9vGdK2NqAoOjogIDq6KqK2tqqol9tSHZH1yBZrRJGg0opz7
KMcobBvTNpltR6JoLCUqVYQmFtejkVBGYJmnqlCADCIZgomtkDCI8wwU7dH9DAfIv+ewx4oJT3oQ
FO2wqCPBWFFZRj4BdDmQFxT7F+GJ1pHZZi5RWLPg5Tnhy9eNUk+4qxa2w271btVvjfKcPvvZ1YHN
KyHGKTpWEU2eq9F8rq0gHrFWXWt7zgek4H0Ei9E8R7U2PYv4royLJ/Nyzhxu1lZYvGewMhFCiMte
ok2wCUe5Ok8GiRCVkERc9kBs78hH/mMnpRDE9LUZtjazxbDFsXjQiI9HueJuRrSC43v/qSnvSeOB
iMHkFYh+8BiJSjmdHnJhN4Mu0fWw36JnvuqNqq3gBxu1vr/TM2sjtAkIkwjPCdGctoXs7+1qKf06
WUe0RjASGW36HavYt13+xytV69x78L95q/rfYq+EezPyN7++jb35+jb2oK0ErwqkFW0DyUj6KkL4
aiB/iy07vjdvl8XbBqkC1WS8hEXaMFvavlTr/ckkLFemquR4RLuHI57AJ6ozVFlkKN1+AkyWVCvn
Wau0RethW3McKqDA1zDHEUvaZ+CJvEytI45D9y+fvwIZ6QU+yLW9zVGXoksuhCLQZmcUosl8piP6
qD3L9ksn228tQykh4n5m3l0vQC1XhagFTWYnWGh0BrfN0jKthCqb4UhHy3SI9L1n5qH8RloPWXEp
SsstKj7ZvpWkBBnNLFaKkJJ/w468WVqDuvyIFhtQ39sOh55uNKPo+0RR+dVoE4u6T36GqY1b4vx8
ObSW1svr08j4inpdeFiYpcxMU6tAmS6JStkQNR88YVO2a0WqTkXMHJMMqXESfJCOgdSibK0uK4PL
L2k6ehNawbgpJ6bER+sF6xnxK4JVlwj3CC+fsE2kcCuOxH6uI2kjXFlfaqyqijX6J/ilbZp4fgTq
KhH/FTE//4DEFhvASyq2odaBLx3qUQ+p4bLlo6/4b2g0f5c9GbF/i19MaFhYaWijvigvi7CvVqPR
AKOFBEVA2qzFSyRJSeSESiYtU5GZf/sb1I1Da976T5ZZM8cPqrz9cLfRofkB8nq08EFfcTtyRDfZ
KppI2JuNh6ua5VsNXLwnbA6sijeUbM/dddLt0w9xH9yf2OYwifgV1iNm9mMk/P4vZJ34/R+wkBO3
zwOfdVEbGdQdX2EXQ9BJeXFMC9wgs9+1umcPSg7AEjNX5gPriORthPWxvkEumwhVWzAireC/uCo4
Zvz+kZAP5V+yuZZrkQoGK0TYHlSFinImXOSPPQgJ60pyzxQWZGddg0JST0+RLG4KFkj9x+H+/lgC
75ICbj5wAPbncYdp+Ez3Wc7RjMqiu/tOMza4fHkclZKYD0XuQ6Z9kYcsl+6T+E3spu2KHVDKnPqi
+eKls2tnrfDa6OLHGeLZr5sOtsI55tH7x8cO/WjGmBjt5mZXLj+pKdxIhO758uCJK4f1G/jz/BfI
7vvbf22U7fdu5qIr4vIW7WaGurOo19Sa6JYgWOo0Y/rayRNnnb59ou7sty2chdZeopCXgrsvhWgV
b8/+kxbha3+gT2g7Xl2BpltWOtx9GU2A89MfrxY/jm4XsoTmpy6akZb6W+2/voGYWtXl1Z1wydSC
RsNla/K1OdkW0/EanHdtuOSRx3+ISwvSuZcDUWuU3gGNMkhRj8uWDwvUjfxK1hRb7RuVkCyXc2qV
Wq0GRgVFGXXZX585LSmw1F3HZKdnpMs+nIa7uVRt3ttQVm2yQP0/WWbPO2JdxauVesHTE0J0B6ex
RBK1saW4N3IIQMsBjQY0cyeaiXqh3oUdL1Ho5Mnj5mHxMm4d7pKEhYSlp+bjnp9hu5O4192FecBk
ZeiyJb+9GsWRdzcjHQvXZKjnKmTngnpN/CIZGLlCIVeCqjxG8uOw43g8YG/A03zwbPwmdki0JU2e
ocjKe/AVEn/OHUZdCpAQ7jAd3waaA/ci+n6j5RsDtPiRxe8cQrf5weyB7EQPCa783+WPF9LYISVO
bUmUk/i2WqWChP64G7ITPb27+/T2xuRIPeehkodAHONvSiyvrCzZ/vmq5hljcPd1WMBh0T+MUn+8
BbpK20BpQU0FQc0bNtS4adizEXs8O0FTUpCVk8dptXYajTphUchSN1eJXE5OpbACpuD6dUQTcN9F
LicE+ahMiGqRC3sCly0ns6wSkTEQeIWQV6Ac1tCukNLW5rF1zpF/hr5l0rLV5BjfV8gvbHNlMwst
FWfyU3JlCYrkZCWH//K3memJxISqnGS5KflFGXl5OislGtocDYJdt1HObSG/BV1i4Ub6Db/Lm36Y
XOIOLjAzzGNMwNz0qfAxTM8Yt2fa3o8uRR2Eo/BNxb7v685nXoPrDPbFl1gvWGaM+UF2Eh7B53AW
zuUcLUfdr+QayZx/LqZ8WN5KmAaLiUeaJ1sUP2pF0GawSSTfZN5HkBR6mShkWx+2CrSR3JJF4yEA
mECig59Dq4lpLyZqnDSOC7DMoPfIaLsb7nXMoAH0OGV+k0Vi4Cp68eIns8OhF8jtoW36F19lXz5H
YxF38ig8c0KicTewPbab8d77Kw+BrrShYI8pxuSXqgK1kqv84mjTCWAe7v1o8sfrp6xaIsGrsL/M
ch0T4SR+wdOiGjTTLlyUHpTmlhyflrqA2E0bs15EZCysRN1+Ok3oFXX94Gf08aNpz/uKMYX2ohfs
reoTF0iGbo0/NnLINJdp/oboWrPeUHvIFeI588FzhY3A7PlMOi5JtTzMTRK0casyXJ2qjlClQao6
TQ3JjLhdJsuGUm6f6FbTvOF4wNxgty3TSz/3kzSkmw2wk2kM1QdHBCS4jX28AAmQ/cOHP3Nka7i1
+No7FeSAN2w2O9NAbDbyOff4npBfZfmmhzaTlmBE9z9t2f+HdwuNfjtWLnPzVqRzwU0rM0OBGYWZ
tZiS/Jv9gXz+9DoC11nGUTv6ya3mLw7WRIOGU9OxqiiLS5drwqtTiF9PIfM8pukOQ2tlhUf1Vlbw
7SSGwzL+l/8DM3gpNyhSYaPCSXyH+neZYfwKz/gYLrLBXb8emNH4DUIT/3YafP8NKllAnJ0/OcSz
e7s+r2pID6nmvFQpERAF0oK4snSmM3qk0Ms6Y/clkT9tG0YC/7P383+jfeV24tsKUGsU2oAiDzK6
zYHVUp+gbXtW5nsAMxyL1jj/v8Tz5Gbzl6U7lHEmLlkVlgL+EJ8Va0hVWoYuGUPoU2R77PE3By7n
VkNKDZeiiEuGMIjJiS+VM/ZSAz+rFAXnZxlE2KOANnc7353r1nWSvscbhtwePc7re/SkqP8Bwzsc
5wplbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h
bWUvRENOWU1BK0NNQlgxMi9Gb250QkJveFswIC0yMDEgOTEzIDcwMF0vRmxhZ3MgNAovQXNjZW50
IDcwMAovQ2FwSGVpZ2h0IDcwMAovRGVzY2VudCAtMjAxCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAx
MzYKL01pc3NpbmdXaWR0aCA1MDAKL0NoYXJTZXQoL0EvQy9EL0UvSC9JL0svTC9QL1IvUy9UL1Uv
YS9iL2MvZC9lL2YvZmZpL2ZpL2ZvdXIvZy9oL2kvay9sL20vbi9vL29uZS9wL3BlcmlvZC9xL3Iv
cy90L3RocmVlL3R3by91L3Yvdy94L3kpL0ZvbnRGaWxlMyA3OCAwIFI+PgplbmRvYmoKNzggMCBv
YmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggNDIyMD4+c3Ry
ZWFtCnicnVgJVFNXt74xJPeKiFNvlWpvcMIJFdS/iq21FsURxREVhwRBQBlkCqDIZIAkOwGZFWRG
ZAgiCnEsWv2lrXawdWj7W6vLofZvqbRaui8eut47Aay+1vdW37/OYpGsu9c9++z9ffv7TiSMVS9G
IpGwru7vrnWeYvnoIA6ViMN6ia9LgWx8OrrDQwY2UrCxOjqMnzQQ7wzA1H64rj8jlUhCIjWuITti
wgL8/CPsx24ZZ+/s4jLd0X6Kk5OL/Zwg37CALapge3dVhL9vkCqCfgm0XxmyJcA3IsZ+7Fv+ERE7
Zk6eHBUVNUkVFD4pJMzv7XGO9lEBEf72K3zDfcPUvj72biHBEfZLVUG+9t3ZTer+5xoStCMywjfM
3j3ExzcsmGEYxznBIa475obOCwuPWBC5UB2lWhztvSRmi4/vVg8//xUBK1dtXx0YNM1mkvOUqbYM
M4JZxngwo5jlzGhmBePArGRWMauZccwaZjzjyaxl3mUcmXWMKzORWc/MZeYxbsx8xplZwCxkpjKL
mGnMP5glzBuMO7OU4Zkgph8zkBnEvCLpw0ykpWSsmATmR8k8ycVeM3oZe7VLl0qrrBZaGWQymZes
UPZf8gpWwZ7iVnHvcaR3Qu8H1musm/sM6xNp85ZNTd8lffNsZ9nq+43td7Df1/2j+384YNGAbQOO
DBw58OQgjai17XgAZnQyi4uKJeKmDhdeU6jbGw5hoEvRxBBD529DNLtAF6IN06ZCJHAxSvlB4wdQ
BZVwDcp079mMNLOR4AshuWnZYDSmn8NXh2CJ/BJxkk1UymuNrdAAtfALVHSFOrLkrriLR440yshu
uW2HDMyitUmCUpTgJpRIxUPYwv/gfYb0cnX3fydA0GMvOZm1R6ZkP8oEHwX53E3JlhmvwiG6nu3v
hgEsMjfPXT5SEj5bIJUvC2FtxZbkevE1k6QGbTAPbaRiJYbwOHTyI+JMpk8bSV4lgx9ORGecfvcR
DhSIkSznyauAvW+dgveK6hWlx04UmuGfUL/jQEixH3iCFzcDCEd4wbbjXLwZPYtxUQl6myUf4XDR
0CTtSOyYxpdBWqTwjuvK0wvK54Ad2UMmkdFkK/HGcWQc6tANWbRF6wPJhtjEREjQK5KII+E9nWER
TC1cecm/Yft5QAF+yr926sLlG205p+EGYF9VNZlrTMqGPODKwFiuoEUka8w42iQOrpc8oXXMoKfD
w2QC74ar5BWRx8M+AA5f/+1bdEBh0n0y1GNt1PYtirMsmfNHXTuz/lo0N7GRP3L6XMFR4D5u8SBD
yGjXtYuVytJTgXTLx7RvrWYJjsJB4jAcJm3oeJdXtne2DleKLiyuwrHYD7ehmjhiP+KhIB6/D+bF
VhzP3oXPA454VnkXrQfCA+kd6+m/wX/jgm3OwNmKD56fo4F2KcOChwPiGn6rfM0M/+b1tQtpDYWR
/yAjyMi2N3BIQ3PWmbMKsuml/R6JZbzqLY+4bcAtXtaCQ9Hhy1MtX5+YuZEmr6aAbzJjwWlL/kPQ
hXZrjSVcribjts4i7wJHnLCpRf5jjvdsRRNWq+TvJKomCB5YgE5ynAimRfmE55rkwZgo6/yVHvvh
cGWHTG4rbu5G85Mnj5GTog9G8qZMnIq9hd0Jmp0Qw3mbdlZUmA40Nnse8norwE21m+JbKicz/ozv
G/QoVfANlHcdZhoF77Jkk2hfLWn4DHd9JhX7irP5IsiMTdZBUqyQqk3QpGhDCrZm+AEXRMYDeXUE
9o+sSVFUppiS0+FY0rEwUHFvO4F67ZKC1hAhuVhv2AmcGrQRCsKy0aDJzzRCQbFwsOiE//tQCHbn
cUAe2p0ONUUVKrzrAjJW5yzOXZYLp7mP70MJSjPmhRkFQ1yWBYMlkFamsBUXUnaxZpxdLPmFQrBv
kxT9xNE8jjKTUbhSJdeP9Ro7Vstt+4bUsMNvRVy9fvzCdeGcypNdGBQcuAw+LRNsn0ppW06YsdDc
3ZabOETaEd4xmG83y4N19uBHlz0EG2lJlO2kkNzEwnYz+5cnFgyyVcbfoJ6u36Cqq4TD8QTeJCde
9oSl/KHF5ZqfDyFsF5fyzzqylp29aemsd1Irzgv4I0vcnvcqkR3zafBv5dfhG7NgmCnHORkyM+uu
gaMK0Yq27I0eioyk58BD9BxoZZb76caAiq4x4NeVLlp1thIrJVtvbIMmutqgvistYnnDg5QSkTdL
xD2iLZ+Zn551CTgz66fTgTfsAB2s6HoDW1maotGDPiVRQXqTHMJjney8WR6hm0eDgmE5hHaFXWJx
bufA7GhjShnYFUCWMbuYo5Ore4cOH7Evn3kgLfOiZYdgXRwtqDfE9eTIZp+BOLpDaqJiBNlHWGyQ
/dMsD9d50A3W0jzWdUW1sGl79salJ6Ul54RDCui0Gr12Nlk+hDBYZImP0M2n8dvBC4J64nFi54DM
mHRNKdjlUiRlFbdj4ZB2UpAdaflqVwppGZmFdCyYk03oXYnTTJI62iJvy1RQ4ln+4bsfkeEriXXK
dFVtTGV1VUlDkaZwZ65gyi6HIuA+a/R1UWxhyRQydTOROiEXdeWrM03HixVbQfmz0CwvyYLSkiTY
rVhigAIo44jkAj9xesz29d6mk98hU/PTXgpJqz/G3BCpGCDO5DEJN+3Lzc66D3ZmdhltxSYIglkQ
1l2oUijXH0zk9GynNbkqw9v/D3xuYx/fQ19Sa9Smp0CqXcJ6iBSUbK3xe6qf1fDvnrm2g10NqXsT
91uGJWXLU5raAwSqp2iXuy8761tLVitpVgG080oI6c6qqCRFQ8Vcp1NMGzcW+8qanjUjCFb3xHzB
ohNZQTVwTPxujWYG2CnZD4xGqKFTqAkOdat8tHpvpgEMmVmKNpShlAyVqZTycuOndFZVw7meqHk9
dHrNhKub6SDEXIsY+XQs4l9Um5+b2ANFB4oKipvXnE84RtVJaL+No/H1iQ/I6x4bord7K/Z68YdP
ny1sos/6Axm0cBOsCN+qCPTakLgd5sPW07tLKXqnv9CdDq5rgmvcdtGOLwDOnsqNnVm+XjcF1sBW
IPIX6y9etLCLbDCJH5slpRZA7RH78Rn707MuWwgQoEv9nxQznII4rTZZr7VQbC95BastFAunRQyh
hfboodhlFt07R6fE7w5OibdTb9ruNg9SIR4SMoyG6jxo4EzhJUGB4eqADcdVH9x6//rxYsFW1NKx
2SN389FaKvpjbz4vARJ36fXxKYImeseCyVSNhgM6nmgx4GAcnNmiS9Hr9Tq9QquNi4UwTlW3s6Kk
Yd+pW4TNWE3c5lFPwpJhP0zGMehcg1ym8GJDnskqtln0umeObWIjizZXudF9RjhMJfZk5KM30O78
qSLTUYUni27Pp5rIEknnA161dG0cVRrSH3DQJ9QdlTYoai60ZJRBIxyPMW2m2MxJrseVVfh2t9tK
eigV12IoX5YBFdWaGxtPKVRNK/ctt6jsG6PJQGL/2Akn4IQT7QfyYyF5l14bl6wIXbRQ7UUjRutx
6AVFlZWx0XC0pL6o9nCpmZImm9gY1nG2+GMXBzCcGkjZk/sWzQ2yiI7cTPo8lj/5pMCUa9TrMoTY
xKSdoOa21MYcLK3PP97o1zTXiUh9CSeMnqO8Tp6+XHM7sunb8xvwXLfNwVM4XIpVeJHHt+X45vd3
HiPjeIe4KDodu0El/6u04GtiK4+TwWX+QphOJiuIAs9Rm9BCNtbilIc3ajGuTlJzC8PbM25J8VVc
xJ8OvQD5Fj6c/+rz5uD6+BxFVUF5+gGjNoW67zhOvT/64MH9RSXlMbUqpbc6Ri14l/tkr6V1Ela9
PS8wx7spQLEzOsafzhtl2daSXeHJ7hGwgvP4eAEuwZm3379xb3lVWJ7gVb4YplKHvxlSDMrM+AY6
LrMM+bn7OOyTwU+DKydPwpW7d8Ft40Zwm6a4QLz4a5/Hefr7L6cmcIjfhYbLlyBf8cy7W2D1Evvu
sH5ukMXe/CR/kfgX/2P73nEz3qQ24xET1psHdvWjAYcPHhQrHsTvqY2vN12F97m2EbeJu9Ap+6Mh
T7oa8usfU/YIO+gM9pEfg9r40tDqAHqhWUCXd3PAWf9b+lLgfsl7sP/AnrS4aL0mTq9IWReoDoHF
oPl0z0NuUGzyOc11wpgoHYt50hvr6YtwepqLxyr9NPKmwhY/pngRm3/GURY0SjG8Q8o3bqvx8Q4M
8PWtCWg8aqppFMhcspASr+UFs3eFXqUOweUe4LmLEywjNN7cwR6TfPQArz2QYqa4hB9bqr0K+7lm
U0tr690NZHCJkKYGfVGP/0IP1uIHNVp9YpKgXB9Wsu7oeGqWR852JpIF9Rv271ac9TyU/CSiLTJP
V6reF1cVAms5pfotYjWVKKrRYY+gL4S0qGee0KPbExoM2TlCbm72voqKixtvxVmuEU6ftLf/2/0B
kVRQAJRRANw7K8GvLfPXh14dfx8jjyKJsiZ5Nkqy7uAo4L7pvEcmKOU3jY+hDj6EL+Fmt72ZIN67
ydKArOnZpBe10s/0DL0sqiHFO2jiceAveTm52Vcsohaqi6JTPBRWQkT3SM4r1+5JTU6lokYWEQeZ
qGT/ijNLZSvhyh84e40tyMvfV1qIfYnTkMw9dL7rucQo2E2Fttz4CQ1thv3Q1K12uyAKEgy701LT
EqjadvwabxbFbqkRR5ykpxU7eCg1GA6mFxqLDYX0KmYR1VlUD0KoHejOsYytBCOUa6tSDXqI5DoH
sGSkw3JiTVxT8bWLgjjjpfbAmSXUBPXCjeh+m94PBwpdwBJbm7tRFfQnKe0+6RddJ/3iOV2eznrh
Yr25+0/acYey86HPWWLlsGH+9l3Crjvz8xfDBPB0V3txf/umLfnm7KUjpZGz/heq/o0Qy2Wcdlve
9ZsDfmWZG/PQmW81jxfnyCv06WExOoiNF0hr5zKZEo8QOZFYLNMjSuU6eASVXW8ZT8VIDOHJFwTY
rlmET89eQ5sSy/ULfWil2sRVfCoZ1cZSt2Kdcyy3HqKqhcDEuHAI5bZWhteZDpU1nN900YG+3jGA
9BUcnmvBn8qJT3EeW5Gh91eQGy97Lk5iLU2ixL+No6QYfbWL9z7bAr29TYFHu3jfdWIxzXycHng3
yqT4qIPlq3SwXZizmEgtP6xEK4vkh+FcxrF9XGcpUSjZJuOvcIqu9h5Ikte76obWeBntms2SC2iH
HviKVDTidup8tGqNR2ziHs0siKV6MFneUPvdl/m5KP32s2b4kUNr+y/o9JaNX+y4xhxbVlNfcrIp
sCQwXTh28lx6CXAPj7/jOmuNq7dSQYJIVGIS5UaM3U5xhmXL+GNHUcCBh2/jK031kq+xF7pbpHA/
3qZXGhjptQmGE0a9MK3OS2HOzq+Baq4xuMpbFRysmty2Gvuhy7++azsT9gOZXCncq/zwI/gXd8P1
ElEQKxePmeuO7jpYdbjoZFli3YZMoanxM8gA7j64BQWlbqQ2MDQgVOeri9dH6VN1yVrQQCq3MwOo
cbLgG38/cw37FfY03NLzjjF/s+dvLokLXC2oji+HGFosGRlPAaD4PwHg8x9D4/feSXwbe/9G3c0D
tbqYSiEoKVZNrbc6K7oogZvM2sbniR7ZuLk4J09ONmayZmuU9BGsraYX2/Suy7axQUmZTV+DjS3D
/Deid4X0CmVuZHN0cmVhbQplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlw
ZS9YTUwvTGVuZ3RoIDEzOTI+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBN
cENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8
eDp4bXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAy
LjkuMS0xMywgZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53
My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9i
ZS5jb20vaVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmQ2YWI3NjRm
LTk5NjMtMTFlZi0wMDAwLTQ3ZWI5YzhiZDViNScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUu
Y29tL3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjEwJy8+CjxyZGY6
RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmQ2YWI3NjRmLTk5NjMtMTFlZi0wMDAwLTQ3ZWI5
YzhiZDViNScgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1v
ZGlmeURhdGU+MjAxNC0xMC0zMVQxNzo0NTo1NC0wNDowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6
Q3JlYXRlRGF0ZT4yMDE0LTEwLTMxVDE3OjQ1OjU0LTA0OjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHht
cDpDcmVhdG9yVG9vbD5kdmlwcyhrKSA1Ljk5NCBDb3B5cmlnaHQgMjAxNCBSYWRpY2FsIEV5ZSBT
b2Z0d2FyZTwveG1wOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0
aW9uIHJkZjphYm91dD0ndXVpZDpkNmFiNzY0Zi05OTYzLTExZWYtMDAwMC00N2ViOWM4YmQ1YjUn
IHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1
bWVudElEPSd1dWlkOmQ2YWI3NjRmLTk5NjMtMTFlZi0wMDAwLTQ3ZWI5YzhiZDViNScvPgo8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDpkNmFiNzY0Zi05OTYzLTExZWYtMDAwMC00N2Vi
OWM4YmQ1YjUnIHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6
Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDps
YW5nPSd4LWRlZmF1bHQnPnByb2JsZW1fc3RhdGVtZW50LXYzLmR2aTwvcmRmOmxpPjwvcmRmOkFs
dD48L2RjOnRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8L3JkZjpSREY+CjwveDp4bXBtZXRhPgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4KZW5kc3Ry
ZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjEwKQovQ3Jl
YXRpb25EYXRlKEQ6MjAxNDEwMzExNzQ1NTQtMDQnMDAnKQovTW9kRGF0ZShEOjIwMTQxMDMxMTc0
NTU0LTA0JzAwJykKL0NyZWF0b3IoZHZpcHNcKGtcKSA1Ljk5NCBDb3B5cmlnaHQgMjAxNCBSYWRp
Y2FsIEV5ZSBTb2Z0d2FyZSkKL1RpdGxlKHByb2JsZW1fc3RhdGVtZW50LXYzLmR2aSk+PmVuZG9i
agp4cmVmCjAgODcKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDM0OTk3IDAwMDAwIG4gCjAwMDAw
ODIwMzQgMDAwMDAgbiAKMDAwMDAzNDg5NiAwMDAwMCBuIAowMDAwMDMzNzY0IDAwMDAwIG4gCjAw
MDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNDg0OCAwMDAwMCBuIAowMDAwMDM1MDYyIDAwMDAwIG4g
CjAwMDAwMzY4MTYgMDAwMDAgbiAKMDAwMDA0ODE0NCAwMDAwMCBuIAowMDAwMDM2NTI3IDAwMDAw
IG4gCjAwMDAwNDYxNTMgMDAwMDAgbiAKMDAwMDAzNjI1OCAwMDAwMCBuIAowMDAwMDQ0ODEzIDAw
MDAwIG4gCjAwMDAwMzU4NzYgMDAwMDAgbiAKMDAwMDA0MDk5NyAwMDAwMCBuIAowMDAwMDQwNDU1
IDAwMDAwIG4gCjAwMDAwNzU5NDMgMDAwMDAgbiAKMDAwMDAzOTc5MCAwMDAwMCBuIAowMDAwMDY4
MzY2IDAwMDAwIG4gCjAwMDAwMzkyNjQgMDAwMDAgbiAKMDAwMDA2Mzc5MSAwMDAwMCBuIAowMDAw
MDM4ODI5IDAwMDAwIG4gCjAwMDAwNjExNTEgMDAwMDAgbiAKMDAwMDAzODQ1NyAwMDAwMCBuIAow
MDAwMDU4NTczIDAwMDAwIG4gCjAwMDAwMzUxMDMgMDAwMDAgbiAKMDAwMDAzNTEzMyAwMDAwMCBu
IAowMDAwMDMzOTI0IDAwMDAwIG4gCjAwMDAwMDQ4NjggMDAwMDAgbiAKMDAwMDAxMDI5OSAwMDAw
MCBuIAowMDAwMDM1MjUxIDAwMDAwIG4gCjAwMDAwMzUyODEgMDAwMDAgbiAKMDAwMDAzNDA4NiAw
MDAwMCBuIAowMDAwMDEwMzIwIDAwMDAwIG4gCjAwMDAwMTYxODEgMDAwMDAgbiAKMDAwMDAzODI5
MiAwMDAwMCBuIAowMDAwMDU3NTc3IDAwMDAwIG4gCjAwMDAwMzgxMjcgMDAwMDAgbiAKMDAwMDA1
NjU3OCAwMDAwMCBuIAowMDAwMDM3NTI4IDAwMDAwIG4gCjAwMDAwNTEzNTMgMDAwMDAgbiAKMDAw
MDAzNTM0NiAwMDAwMCBuIAowMDAwMDM1Mzc2IDAwMDAwIG4gCjAwMDAwMzQyNDggMDAwMDAgbiAK
MDAwMDAxNjIwMiAwMDAwMCBuIAowMDAwMDIxOTQzIDAwMDAwIG4gCjAwMDAwMzU0ODUgMDAwMDAg
biAKMDAwMDAzNTUxNSAwMDAwMCBuIAowMDAwMDM0NDEwIDAwMDAwIG4gCjAwMDAwMjE5NjQgMDAw
MDAgbiAKMDAwMDAyNzE1NCAwMDAwMCBuIAowMDAwMDM1NjAyIDAwMDAwIG4gCjAwMDAwMzU2MzIg
MDAwMDAgbiAKMDAwMDAzNDU3MiAwMDAwMCBuIAowMDAwMDI3MTc1IDAwMDAwIG4gCjAwMDAwMzMw
NDkgMDAwMDAgbiAKMDAwMDAzNzI5NCAwMDAwMCBuIAowMDAwMDUwNzQ5IDAwMDAwIG4gCjAwMDAw
MzU2ODYgMDAwMDAgbiAKMDAwMDAzNTcxNiAwMDAwMCBuIAowMDAwMDM0NzM0IDAwMDAwIG4gCjAw
MDAwMzMwNzAgMDAwMDAgbiAKMDAwMDAzMzc0NCAwMDAwMCBuIAowMDAwMDM1ODE0IDAwMDAwIG4g
CjAwMDAwMzU4NDQgMDAwMDAgbiAKMDAwMDA0MTMxNiAwMDAwMCBuIAowMDAwMDQ1MDUwIDAwMDAw
IG4gCjAwMDAwNDY0MDQgMDAwMDAgbiAKMDAwMDA0ODQwNCAwMDAwMCBuIAowMDAwMDUwOTkxIDAw
MDAwIG4gCjAwMDAwNTE3NTAgMDAwMDAgbiAKMDAwMDA1NjgwNiAwMDAwMCBuIAowMDAwMDU3ODA1
IDAwMDAwIG4gCjAwMDAwNTg4ODIgMDAwMDAgbiAKMDAwMDA2MTQyOCAwMDAwMCBuIAowMDAwMDY0
MTEwIDAwMDAwIG4gCjAwMDAwNjg4MzUgMDAwMDAgbiAKMDAwMDA3NjI2MCAwMDAwMCBuIAowMDAw
MDM3MjEwIDAwMDAwIG4gCjAwMDAwMzc0NDAgMDAwMDAgbiAKMDAwMDAzNzk4OSAwMDAwMCBuIAow
MDAwMDM5MTcyIDAwMDAwIG4gCjAwMDAwMzk3MDUgMDAwMDAgbiAKMDAwMDA0MDI5OSAwMDAwMCBu
IAowMDAwMDQwOTA2IDAwMDAwIG4gCjAwMDAwODA1NjUgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6
ZSA4NyAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxFQjlDMURDNTMzRTlFQUQ5NUVCQUEw
RDE0MkRBMzUxQj48RUI5QzFEQzUzM0U5RUFEOTVFQkFBMEQxNDJEQTM1MUI+XQo+PgpzdGFydHhy
ZWYKODIyNTMKJSVFT0YK
--001a1141f3924e910a05070a4f89--


From nobody Tue Nov  4 09:00:50 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89F81A9149 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 09:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWzt8sonGaUs for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 09:00:47 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCF71A0AFE for <dbound@ietf.org>; Tue,  4 Nov 2014 09:00:47 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id rd18so8035392iec.13 for <dbound@ietf.org>; Tue, 04 Nov 2014 09:00:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=za/1dmE64e+wjpoUeLe4Be23zH+GeiSuxlDYgha9Q/0=; b=Wh42RDVOz6j3Hq+bivzgZXSLOAvEQKKNjssR1RUhh8fcur3VdOx/f/O5H0zRs9fnDp nVoyUfzfRcJvkGiH2Suk41CCcrze5bTHNIcUISsBUbf0vazsB617cRbSfWCEMC40yGWa FhAE1xoiaM/332yG8jbNx1vh3JZtxicFamNCU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=za/1dmE64e+wjpoUeLe4Be23zH+GeiSuxlDYgha9Q/0=; b=Cv84Y9S8hqrWn6ZWhK3PyWQflWoz8/IYxEjkuPoJajQY3uuXVQvECE4OdddFl9kc2v eS6ANBxeoNuSiHhQ3IVI0z9R8MLBy4rG20yaShr1+5bcFTncuam3z9u4KxQkLY3nu8ru aJxiB/NOVVhmGq6YYAgHuY8G1vGFh9T1tfHsIh6kapOo+Icoav+1WwdsjRnYk/nD5Q7S Q1hwzLD+wZPXJBedWg0PpMDBr45djKz8jxLevn499APWLkokJjVCcAMECYBl8Ge794HO WZYAp2pBh0KmUxDRAstApVaV+6X5IGYVyX1+hXxkGsMqMZTqCukCSoFV6fxc5vdDxEeY oVPA==
X-Gm-Message-State: ALoCoQk43xyvXwsOh6AwkI8jcILLEVJWviZZ+nSAyVr8izVovNC9A5VA3ePL4/S2KX3eB7HbhRaD
MIME-Version: 1.0
X-Received: by 10.42.184.74 with SMTP id cj10mr3268559icb.80.1415120446647; Tue, 04 Nov 2014 09:00:46 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Tue, 4 Nov 2014 09:00:46 -0800 (PST)
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
Date: Tue, 4 Nov 2014 12:00:46 -0500
Message-ID: <CAEKtLiRawTO+42=OqqA0AwCTr=iJTq2FTYO-scNJpAHOxQ0=Dg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=20cf303f6ea889847605070b67b5
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6fgD1fl7-2HaX168EBrGqEivMbo
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 17:00:48 -0000

--20cf303f6ea889847605070b67b5
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 4, 2014 at 10:42 AM, Casey Deccio <casey@deccio.net> wrote:

> All,
>
> Please find attached a draft DBOUND problem statement, resulting from the
> action items taken at the bar BoF in Toronto on the same subject.  Please
> take a read and comment on the document.  There is probably a better format
> for this, but it's a start for now...
>
> Also, if there's interest in a follow-up "bar BoF" (i.e., "unofficial"
> meeting on the subject) in Honolulu, I'm happy to help organize one.  I am
> proposing such a meeting during the Thurs morning session, with alternate
> times being Wed afternoon II and Thurs afternoon III.  If there are enough
> BoF-interested parties that can't make Thurs morning, we can have a doodle
> poll to solidify a time.
>
> In summary:
> - Please read the draft problem statement (attached)
> - Is there some interest in a DBOUND bar BoF?
> - Are there Thurs morning conflicts with a DBOUND bar BoF?
>
>
Update: There was a venue conflict with the Thursday time, so I'm proposing
Tuesday morning in its place.

Thanks,
Casey

--20cf303f6ea889847605070b67b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 4, 2014 at 10:42 AM, Casey Deccio <span dir=3D=
"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@decci=
o.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Al=
l,<br><br></div>Please find attached a draft DBOUND problem statement, resu=
lting from the action items taken at the bar BoF in Toronto on the same sub=
ject.=C2=A0 Please take a read and comment on the document.=C2=A0 There is =
probably a better format for this, but it&#39;s a start for now...<br><br><=
/div>Also, if there&#39;s interest in a follow-up &quot;bar BoF&quot; (i.e.=
, &quot;unofficial&quot; meeting on the subject) in Honolulu, I&#39;m happy=
 to help organize one.=C2=A0 I am proposing such a meeting during the Thurs=
 morning session, with alternate times being Wed afternoon II and Thurs aft=
ernoon III.=C2=A0 If there are enough BoF-interested parties that can&#39;t=
 make Thurs morning, we can have a doodle poll to solidify a time.<br><br><=
/div><div>In summary:<br></div><div>- Please read the draft problem stateme=
nt (attached)<br></div><div>- Is there some interest in a DBOUND bar BoF?<b=
r></div><div>- Are there Thurs morning conflicts with a DBOUND bar BoF?<br>=
</div><div><div><div><div><div><br></div></div></div></div></div></div></bl=
ockquote><div><br></div><div>Update: There was a venue conflict with the Th=
ursday time, so I&#39;m proposing Tuesday morning in its place.<br><br></di=
v><div>Thanks,<br></div><div>Casey<br></div></div></div></div>

--20cf303f6ea889847605070b67b5--


From nobody Tue Nov  4 09:55:56 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992DD1ACCE8 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 09:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level: 
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_37=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fSojs5nGVRj for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 09:55:53 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB311AC44D for <dbound@ietf.org>; Tue,  4 Nov 2014 09:55:52 -0800 (PST)
Received: from [81.187.243.93] (port=54502 helo=[192.168.0.103]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1XliKc-0006pE-OR for dbound@ietf.org; Tue, 04 Nov 2014 17:55:51 +0000
Message-ID: <54591324.3040803@mozilla.org>
Date: Tue, 04 Nov 2014 17:55:48 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: dbound@ietf.org
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/l8BalpaRFBk_BjLeHsN5bVuSLdk
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 17:55:54 -0000

On 04/11/14 15:42, Casey Deccio wrote:
> Please find attached a draft DBOUND problem statement, resulting from
> the action items taken at the bar BoF in Toronto on the same subject. 
> Please take a read and comment on the document.  There is probably a
> better format for this, but it's a start for now...

Here are some comments:

* Your "Contrived PSL Entries" table is a little sub-optimal, in that
one would never see those first two entries in the same PSL.

example:   example is public
*.example: All children of example are public

The first of these rules suggests that foo.example is private, the
second that it is public. Your Table 2 is therefore wrong, because the
PSL algorithm states that the longest matching rule applies, and so
foo.example is public, not private (by the second rule).
https://publicsuffix.org/list/ has the algorithm.

Perhaps the rules are intended to stand as 3 standalone examples, but
that's not clear from the presentation.

* "When an SSL certificate is for a wildcard domain, the entire range of
names covered by the wildcard needs to be under the same control."

It's not as simple as that. Google is allowed a cert for *.blogspot.com,
but by your definitions, foo.blogspot.com and bar.blogspot.com are not
under the same control. This is why the PSL is split into two sections -
"ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)

I think that this issue, which is separate from the one in the paragraph
immediately above it, needs a little more elaboration.

* The PSL was originally concieved by Mozilla community members, but is
positioned as a project for the benefit of the whole internet. The fact
that the canonical copy lives in the Firefox source code is an accident
of history, and something we are trying to change:
https://bugzilla.mozilla.org/show_bug.cgi?id=991749

* "The issue of determining relationships between domains that are
lineally connected (i.e., one is an ancestor of another) and within the
same public/private scope is not addressed by the PSL"

Actually, I think it is. If a fictional PSL had:

example
foo.bar.example

Then you would have example being public, bar.example being private, and
foo.bar.example being public. Or is that not what the quoted sentence is
saying?

Gerv


From nobody Tue Nov  4 10:19:39 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB21A1B8C for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 10:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw9oetQXxYuU for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 10:19:37 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2883E1A1B74 for <dbound@ietf.org>; Tue,  4 Nov 2014 10:19:37 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id rd18so8109434iec.35 for <dbound@ietf.org>; Tue, 04 Nov 2014 10:19:36 -0800 (PST)
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-type; bh=InGaziEXS3SXIr8+CiMFCTpFRGOGQNtNeqdPMCi8g+g=; b=vUgY3PhsuOxRt9beKivOZH7qBDDGH8KSsfvPAJLxzuBl/YRNJz+Vsktgpo8qcPE0eK jMjvBv4/1s9TzbuU4k33OnF02TdWSUX3hPVzzhZwR06p8Oq2VpdLZmjbMRO5MTLKnBMY V2KcjP9KmD7HMg1RoH76Zvy/ZeSnZFRM2NHvg0zwEztrOSxLjumqhhlryUjq+y7xCH3a j4AQdtoabfUVgkSYa7r1iygjlNl3KOeyirBcHDYRjoNBpR6CvA+nxrBHHCtHF6kI+oE+ ZrX4nEt1+cdeEW/Zoa5omnBBLXkYsJg8KebOaAYvLgOTaGzKldcLNt9rDQdzph1nrkZZ LZOA==
MIME-Version: 1.0
X-Received: by 10.50.122.106 with SMTP id lr10mr25733504igb.32.1415125176339;  Tue, 04 Nov 2014 10:19:36 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Tue, 4 Nov 2014 10:19:36 -0800 (PST)
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
Date: Tue, 4 Nov 2014 13:19:36 -0500
Message-ID: <CAH8yC8=Qu4S4o=579dGv8-4bQOcnD0VDBFrPBudy+ib+=N3mUg@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/DjuriSOZRyTbi_Zrtiw-Se06eLc
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 18:19:38 -0000

> Please find attached a draft DBOUND problem statement, resulting from the
> action items taken at the bar BoF in Toronto on the same subject.  Please
> take a read and comment on the document.  There is probably a better format
> for this, but it's a start for now...
Thanks for moving this forward.


From nobody Tue Nov  4 11:47:44 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF951A700A for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 11:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ikshAXis6kI for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 11:47:40 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028391A00AF for <dbound@ietf.org>; Tue,  4 Nov 2014 11:47:40 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 4 Nov 2014 11:47:37 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 4 Nov 2014 11:47:37 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: Casey Deccio <casey@deccio.net>, "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWA
Date: Tue, 4 Nov 2014 19:47:36 +0000
Message-ID: <D07E8E77.5405%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [68.98.142.232]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3497957251_3311526"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/WL3MP-vshEh2K2ycj0kR-Gdkngo
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 19:47:43 -0000

--B_3497957251_3311526
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Thanks for writing this up. Now for the complaints. ;)

You lost me at the first sentence of 1.1.1.  (Saying that more
dramatically than I mean to.)

I don=E2=80=99t have a complete response to the paper.  In the spirit that
provoking thoughts is better than not at this point, here are some:

Fragment 1

I once believed that domain names were =E2=80=9Cdot-separated alphanumeric words=E2=
=80=9D
but learned otherwise while working on the so-labeled clarifications on
wild cards.  In order to being to understand how the DNS organism is
architected, one has to view this as a tree.  And, ironically as I deal
increasingly with non-ASCII identifiers, there=E2=80=99s no dot "on the wire.=E2=80=9D
(The root zone isn=E2=80=99t =E2=80=98.=E2=80=99, it=E2=80=99s a zero-valued byte.)

In section 1.1.2 an overly simplified view is given.  Not all domains fit
neatly into the public and private bucket.  Some top-level-domains are not
delegation only.

>From these two comments my mind leads instantly into recommending that
this paper attempt to describe the problem from two very different
viewpoints.

>From the =E2=80=9Csystem-to-be-messed-with=E2=80=9D viewpoint, the nature of the DNS da=
ta
model as being first based on a tree structure must be respected as well
as a clear description of the management model based on the units of
zones.  The DNS protocol permits management of resource record sets,
domain (nodes) as well as zones but does not permit management of a domain
(subtree).  (By the latter, I mean that DNS does not manage =E2=80=98across' a
zone cut.)

>From the =E2=80=9Cpeople-having-a-problem-to-solve=E2=80=9D viewpoint, which you get to=
 in
1.1.3 and 1.1.4, I prefer replacing =E2=80=9Crelated=E2=80=9D with =E2=80=9Cequivalent=E2=80=9D for=
 a
specific purpose.  (I=E2=80=99ve said that before, no need to belabor it now.)
For one, you talk about a parent/child relationship but there=E2=80=99s really no
such thing as that.  A parent delegates the child, the child knows nothing
about it=E2=80=99s parent - there=E2=80=99s no =E2=80=9Crelationship=E2=80=9D as far as the DNS pro=
tocol
is concerned.

Without giving this much thought, cross-domain relationships have been
historically significant, more so in operations than in the protocol.  The
co-mingling of dotCom and dotNet bear this out.

I=E2=80=99m concerned about the problem set-up because, your chances of solving
the problem are better if you=E2=80=99ve properly set up the problem.

Fragment 2

What=E2=80=99s missing from the PSL is a discussion of the registry behind the
PSL.  Looking strictly at the list of entries and concluding we just need
to make that work better is like saying a domain name registry is just a
DNS operator.  I.e., how can you trust that the entries are legitimate?

Fragment 3

This is not related directly to the document, but comes from =E2=80=9CCentralized
vs. Distributed=E2=80=A6=E2=80=9D  One of the issues to think of is - how do we avoid
shared fate when we are looking for a new angle?  I.e., the DNS
distribution model is great for doing just what the PSL wants, but placing
the PSL into the DNS is not helping.  Grossly arguing this way - if we
expect someone to try to register a child and use it to fool people using
the parent, what=E2=80=99s to stop the child from giving out fraudulent
information?  (This is a handwaving argument for why
what-ever-replaces-PSL should have some kind of separation from the DNS.)

On the one hand, following the DNS tree is the best way to track who knows
where the boundaries are.  On the other hand, that=E2=80=99s just the DNS
perspective talking.  And with only one source working here, we aren=E2=80=99t
making corrupting the system any harder than doing nothing at all.

(I=E2=80=99m assuming that all of this is rooted in a security concern related to
the authorization of some information to be applied/accessed/etc.
Therefore, the talk about corrupting, fooling, fraudulent...)

Fragment 4

It=E2=80=99s possible that here are multiple goals here, with a common theme not
clearly defined.  I see a desire to express the policies for a zone (not a
domain) from the registry to a relying party.  This is one use case, not
the only, but one use case.  This is also expressed in a DNS viewpoint.

The relying party applications I can=E2=80=99t speak as well for.

Fragment 5

I=E2=80=99m concerned about the mention of the gTLDs as being either =E2=80=9Ctoo much
detail=E2=80=9D or =E2=80=9Cnot enough detail.=E2=80=9D  The =E2=80=9Cnew class=E2=80=9D of TLDs is only =
special
in two respects - the rapidity that they appear and that they share a set
of operating principles.  If by grouping them you default to grouping
ccTLDs and legacy gTLDs, you haven=E2=80=99t made a useful categorization.  Until
we know what criteria we will use to divide the top-level domains, we
should hold off on this.



-----Original Message-----
From: Casey Deccio <casey@deccio.net>
Date: Tuesday, November 4, 2014 at 10:42
To: "dbound@ietf.org" <dbound@ietf.org>
Subject: [Dbound] Draft problem statement and IETF "bar BoF"

>All,
>
>
>Please find attached a draft DBOUND problem statement, resulting from the
>action items taken at the bar BoF in Toronto on the same subject.  Please
>take a read and comment on the document.  There is probably a better
>format for this, but it's a start for now...
>
>
>Also, if there's interest in a follow-up "bar BoF" (i.e., "unofficial"
>meeting on the subject) in Honolulu, I'm happy to help organize one.  I
>am proposing such a meeting during the Thurs morning session, with
>alternate times being Wed afternoon II and Thurs
> afternoon III.  If there are enough BoF-interested parties that can't
>make Thurs morning, we can have a doodle poll to solidify a time.
>
>
>In summary:
>
>- Please read the draft problem statement (attached)
>
>- Is there some interest in a DBOUND bar BoF?
>
>- Are there Thurs morning conflicts with a DBOUND bar BoF?
>
>
>Thanks,
>Casey
>
>
>
>
>

--B_3497957251_3311526
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTO2+QlkKye0jdxlObE
sefgi2HMgjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDQxOTQ3MzFaMA0GCSqGSIb3DQEBAQUABIIBAKzKXPMN/4ihdB5OtVXw7JCYoo5MWjOshU8j
Mn+oWjHlyu/Z7VAsraHuIM1Cj2W8fdSAZn9YB/mnJ2O9az9QalgChQlsLgCX7ZXbZIbEu6i7
1uo45nLa9BqPXnOsapkqgspgOHCWuLDZGZS8UJ2M5aNlpCWjXenOn8xfPJ6bkCV8YkWSxl7H
H9A0MV6vSszeYkZL0fLu5j+xcaQSKpn4Tvx0c+4Cc0sM+rGI4f7IryjutZajowi47RvieHSU
cDbPsYplSzxob9b3nUvGVbBJJgq4BMLNKaRcVJ042jfglVPchfPmwDbCuoNc3fajN3aNeWQ3
wvM+d6yGBAQJHXnY8BI=

--B_3497957251_3311526--


From nobody Tue Nov  4 11:57:35 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660421A701D for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 11:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjEibE7t2yHd for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 11:57:30 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917341A7013 for <dbound@ietf.org>; Tue,  4 Nov 2014 11:57:30 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tr6so8338479ieb.0 for <dbound@ietf.org>; Tue, 04 Nov 2014 11:57:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28CRQ3DKQiuEOJkTWqFHCDrj0o438l80WJiJPW7tqxU=; b=L+VzUodU/fTgbKHvrBos/b3FQnmI1PedQK5Rk+Qr+ss8Xeu71yTRX7pB8il68VsPuj jpOrIlQ4fLyyFluj+vjqg0vzcTNhIwE1Qlk+Aek1xsGgg9swcIwklXL9oZ5UjmztSMko fNabn5Vz/E1gWmZ7YfFsfhzjjcF04GeLsB8SM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=28CRQ3DKQiuEOJkTWqFHCDrj0o438l80WJiJPW7tqxU=; b=KQ5gycZyk3vKu1VHBjtrJ25vHAhyKE/pqbmbFDx/nmInW++yMvTeg2Ta9Qz33fDECK beNqTWKrQQT+YUbJrM3KZquLehMt7D7IAG9KyDMdnAPBbpQ+1IN8Az6VgvMFduhIpnpH Z8og8SoGPipHMspyQ9IKVJilmz5iN3CiB8j6Ls9SjX29caH0RgD7UbKERzyJy4QeTNCV k07ZLuVhNdw1sSP3TN7XmhLbn8/d43qwiM7zGrfZPabEnCRubjErpdKb1D5/ye66tnk7 bjhRcaUVZlplaI5NxffYAhWV2NRLEaA94Ox/7LtiEFC3lSOOHnnpbn9ic94Tz5NZ0u+j k7ow==
X-Gm-Message-State: ALoCoQnM67fZgl/FPbtKqIBXteX7A2E7PlXLya5PDe/dCw9C5Smqt4cDdO4SE5ReV5kuAmqnjusR
MIME-Version: 1.0
X-Received: by 10.42.236.205 with SMTP id kl13mr119287icb.7.1415131049628; Tue, 04 Nov 2014 11:57:29 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Tue, 4 Nov 2014 11:57:29 -0800 (PST)
In-Reply-To: <54591324.3040803@mozilla.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <54591324.3040803@mozilla.org>
Date: Tue, 4 Nov 2014 14:57:29 -0500
Message-ID: <CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Gervase Markham <gerv@mozilla.org>
Content-Type: multipart/alternative; boundary=20cf302920fa8629cb05070ddf40
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/22pMjPtL1046qky-fdH_pkxV7M4
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 19:57:33 -0000

--20cf302920fa8629cb05070ddf40
Content-Type: text/plain; charset=UTF-8

Hi Gerv,

Thanks for the feedback.

On Tue, Nov 4, 2014 at 12:55 PM, Gervase Markham <gerv@mozilla.org> wrote:

> On 04/11/14 15:42, Casey Deccio wrote:
> > Please find attached a draft DBOUND problem statement, resulting from
> > the action items taken at the bar BoF in Toronto on the same subject.
> > Please take a read and comment on the document.  There is probably a
> > better format for this, but it's a start for now...
>
> Here are some comments:
>
> * Your "Contrived PSL Entries" table is a little sub-optimal, in that
> one would never see those first two entries in the same PSL.
>
> example:   example is public
> *.example: All children of example are public
>
>
The goal was for a simple demonstration of how it works, with minimal
entries, but I can understand how the non-matching entry makes this a less
effective example.  I'll make some changes.  Thanks for the feedback.

Of course, future modifications make some of the remarks below moot, but
just to be sure we're on the same page...


> The first of these rules suggests that foo.example is private, the
> second that it is public


Well, technically the first rule only indicates the example is public.
Whether or not foo.example is effectively private depends on the complete
algorithm, not the stand-alone entry, correct?


> Your Table 2 is therefore wrong, because the
> PSL algorithm states that the longest matching rule applies, and so
> foo.example is public, not private (by the second rule).
> https://publicsuffix.org/list/ has the algorithm.
>

But there is a wildcard exception !foo.example (the third line), and the
algorithm explicitly gives precedence to exceptions.  Doesn't that mean the
third entry (!foo.example) wins?

In fact, I see this example on the public suffix site:
-----
*.tokyo.jp
!metro.tokyo.jp

Cookies *may* be set for foo.bar.tokyo.jp.
Cookies *may not* be set for bar.tokyo.jp.
Cookies *may* be set for metro.tokyo.jp, because the exception overrides
the previous rule.
-----

I read this more generically as:
-----
*.tokyo.jp
!metro.tokyo.jp

foo.bar.tokyo.jp is private
bar.tokyo.jp is public
metro.tokyo.jp is private
-----

Isn't that the same as the following?
-----
*.example
!foo.example

baz.bar.example is private
bar.example is public
foo.example is private
-----


> Perhaps the rules are intended to stand as 3 standalone examples, but
> that's not clear from the presentation.
>

I'll make the examples more clear.  Thanks for the suggestions.


>
> * "When an SSL certificate is for a wildcard domain, the entire range of
> names covered by the wildcard needs to be under the same control."
>
> It's not as simple as that. Google is allowed a cert for *.blogspot.com,
> but by your definitions, foo.blogspot.com and bar.blogspot.com are not
> under the same control. This is why the PSL is split into two sections -
> "ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)
>
>
In the document I've defined the terms more generically.  If I understand
correctly, "ICANN DOMAINS" translates to what are referred to in the
document as "public domains in unbroken public scope", and "PRIVATE
DOMAINS" translates to names "under islands of private scope" (referred to
in the third paragraph of Section 3 and opening paragraph of Section 4).
In the former case, each name in the ancestry is of public scope through
the public boundary in question.  In the latter case, there are one or more
names of private scope prior to the public boundary in question.  There are
probably shorter/better terms for this.


> I think that this issue, which is separate from the one in the paragraph
> immediately above it, needs a little more elaboration.
>
>
In the document I think you're suggesting that I note that (at least in the
case of the SSL wildcard) the different types of public domains might be
treated differently.


> * The PSL was originally concieved by Mozilla community members, but is
> positioned as a project for the benefit of the whole internet. The fact
> that the canonical copy lives in the Firefox source code is an accident
> of history, and something we are trying to change:
> https://bugzilla.mozilla.org/show_bug.cgi?id=991749
>
>
And I think the list a great contribution.  Thanks!

Thanks also for the pointer to the bug reports.  I was unaware of the
efforts.


> * "The issue of determining relationships between domains that are
> lineally connected (i.e., one is an ancestor of another) and within the
> same public/private scope is not addressed by the PSL"
>
> Actually, I think it is. If a fictional PSL had:
>
> example
> foo.bar.example
>
> Then you would have example being public, bar.example being private, and
> foo.bar.example being public. Or is that not what the quoted sentence is
> saying?
>

The sentence is a bit cryptic.  But what it means is the following.  Given
the following two domains, both "private" as far as PSL processing is
concerned:

sub.foo.example
foo.example

Are the two "related"?  The PSL cannot tell us.  It can only tell us
(assuming entries are correct) that there is no public/private boundary
between them.

Casey

--20cf302920fa8629cb05070ddf40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Gerv,<br><br>Thanks for the feedback.<br><div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Nov 4, 2014 at 12:=
55 PM, Gervase Markham <span dir=3D"ltr">&lt;<a href=3D"mailto:gerv@mozilla=
.org" target=3D"_blank">gerv@mozilla.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><span>On 04/11/14 15:42, Casey Dec=
cio wrote:<br>
&gt; Please find attached a draft DBOUND problem statement, resulting from<=
br>
&gt; the action items taken at the bar BoF in Toronto on the same subject.<=
br>
&gt; Please take a read and comment on the document.=C2=A0 There is probabl=
y a<br>
&gt; better format for this, but it&#39;s a start for now...<br>
<br>
</span>Here are some comments:<br>
<br>
* Your &quot;Contrived PSL Entries&quot; table is a little sub-optimal, in =
that<br>
one would never see those first two entries in the same PSL.<br>
<br>
example:=C2=A0 =C2=A0example is public<br>
*.example: All children of example are public<br>
<br></blockquote><div><br></div><div>The goal was for a simple demonstratio=
n of how it works, with minimal entries, but I can understand how the non-m=
atching entry makes this a less effective example.=C2=A0 I&#39;ll make some=
 changes.=C2=A0 Thanks for the feedback.<br></div><div><br></div><div>Of co=
urse, future modifications make some of the remarks below moot, but just to=
 be sure we&#39;re on the same page...<br></div><div>=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
The first of these rules suggests that foo.example is private, the<br>
second that it is public</blockquote><div><br></div><div>Well, technically =
the first rule only indicates the example is public.=C2=A0 Whether or not f=
oo.example is effectively private depends on the complete algorithm, not th=
e stand-alone entry, correct?<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Your Table 2 is therefore wrong, because t=
he<br>
PSL algorithm states that the longest matching rule applies, and so<br>
foo.example is public, not private (by the second rule).<br>
<a href=3D"https://publicsuffix.org/list/" target=3D"_blank">https://public=
suffix.org/list/</a> has the algorithm.<br></blockquote><div><br></div><div=
>But there is a wildcard exception !foo.example (the third line), and the a=
lgorithm explicitly gives precedence to exceptions.=C2=A0 Doesn&#39;t that =
mean the third entry (!foo.example) wins?<br><br></div><div>In fact, I see =
this example on the public suffix site:<br>-----<br>*.<a href=3D"http://tok=
yo.jp" target=3D"_blank">tokyo.jp</a><br>!<a href=3D"http://metro.tokyo.jp"=
 target=3D"_blank">metro.tokyo.jp</a></div><div><br>Cookies <b>may</b> be s=
et for <samp><a href=3D"http://foo.bar.tokyo.jp" target=3D"_blank">foo.bar.=
tokyo.jp</a></samp>.<br>Cookies <b>may not</b> be set for <samp><a href=3D"=
http://bar.tokyo.jp" target=3D"_blank">bar.tokyo.jp</a></samp>.<br>Cookies =
<b>may</b> be set for <samp><a href=3D"http://metro.tokyo.jp" target=3D"_bl=
ank">metro.tokyo.jp</a></samp>, because the exception overrides the previou=
s rule.
            </div><div>-----<br><br></div><div>I read this more generically=
 as:<br>-----<br>*.<a href=3D"http://tokyo.jp" target=3D"_blank">tokyo.jp</=
a><br>!<a href=3D"http://metro.tokyo.jp" target=3D"_blank">metro.tokyo.jp</=
a><br><br><a href=3D"http://foo.bar.tokyo.jp" target=3D"_blank">foo.bar.tok=
yo.jp</a> is private<br></div><div><a href=3D"http://bar.tokyo.jp" target=
=3D"_blank">bar.tokyo.jp</a> is public<br></div><div><a href=3D"http://metr=
o.tokyo.jp" target=3D"_blank">metro.tokyo.jp</a> is private<br>-----<br><br=
></div><div>Isn&#39;t that the same as the following?<br>-----<br></div><di=
v>*.example<br></div><div>!foo.example<br></div><div><br>baz.bar.example is=
 private<br>bar.example is public<br></div><div>foo.example is private<br><=
/div><div>-----<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<br>
Perhaps the rules are intended to stand as 3 standalone examples, but<br>
that&#39;s not clear from the presentation.<br></blockquote><div><br></div>=
<div>I&#39;ll make the examples more clear.=C2=A0 Thanks for the suggestion=
s.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* &quot;When an SSL certificate is for a wildcard domain, the entire range =
of<br>
names covered by the wildcard needs to be under the same control.&quot;<br>
<br>
It&#39;s not as simple as that. Google is allowed a cert for *.<a href=3D"h=
ttp://blogspot.com" target=3D"_blank">blogspot.com</a>,<br>
but by your definitions, <a href=3D"http://foo.blogspot.com" target=3D"_bla=
nk">foo.blogspot.com</a> and <a href=3D"http://bar.blogspot.com" target=3D"=
_blank">bar.blogspot.com</a> are not<br>
under the same control. This is why the PSL is split into two sections -<br=
>
&quot;ICANN DOMAINS&quot; and &quot;PRIVATE DOMAINS&quot;. (Naming is hard.=
)<br>
<br></blockquote><div><br></div><div>In the document I&#39;ve defined the t=
erms more generically.=C2=A0 If I understand correctly, &quot;ICANN DOMAINS=
&quot; translates to what are referred to in the document as &quot;public d=
omains in unbroken public scope&quot;, and &quot;PRIVATE DOMAINS&quot; tran=
slates to names &quot;under islands of private scope&quot; (referred to in =
the third paragraph of Section 3 and opening paragraph of Section 4).=C2=A0=
 In the former case, each name in the ancestry is of public scope through t=
he public boundary in question.=C2=A0 In the latter case, there are one or =
more names of private scope prior to the public boundary in question.=C2=A0=
 There are probably shorter/better terms for this.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
I think that this issue, which is separate from the one in the paragraph<br=
>
immediately above it, needs a little more elaboration.<br>
<br></blockquote><div><br><div>In the document I think you&#39;re suggestin=
g that I note that (at least in the case of the SSL wildcard) the different=
 types of public domains might be treated differently.<br></div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
* The PSL was originally concieved by Mozilla community members, but is<br>
positioned as a project for the benefit of the whole internet. The fact<br>
that the canonical copy lives in the Firefox source code is an accident<br>
of history, and something we are trying to change:<br>
<a href=3D"https://bugzilla.mozilla.org/show_bug.cgi?id=3D991749" target=3D=
"_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=3D991749</a><br>
<br></blockquote><div><br></div><div>And I think the list a great contribut=
ion.=C2=A0 Thanks!<br><br>Thanks also for the pointer to the bug reports.=
=C2=A0 I was unaware of the efforts.<br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
* &quot;The issue of determining relationships between domains that are<br>
lineally connected (i.e., one is an ancestor of another) and within the<br>
same public/private scope is not addressed by the PSL&quot;<br>
<br>
Actually, I think it is. If a fictional PSL had:<br>
<br>
example<br>
foo.bar.example<br>
<br>
Then you would have example being public, bar.example being private, and<br=
>
foo.bar.example being public. Or is that not what the quoted sentence is<br=
>
saying?<br></blockquote><div><br></div><div>The sentence is a bit cryptic.=
=C2=A0 But what it means is the following.=C2=A0 Given the following two do=
mains, both &quot;private&quot; as far as PSL processing is concerned:<br><=
br></div><div>sub.foo.example<br></div><div>foo.example<br><br></div><div>A=
re the two &quot;related&quot;?=C2=A0 The PSL cannot tell us.=C2=A0 It can =
only tell us (assuming entries are correct) that there is no public/private=
 boundary between them. </div><div><br></div><div>Casey</div></div></div></=
div></div>

--20cf302920fa8629cb05070ddf40--


From nobody Tue Nov  4 13:18:09 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994231ACF7F for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 13:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c8R2imSE_qZ for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 13:18:05 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03981ACF6C for <dbound@ietf.org>; Tue,  4 Nov 2014 13:18:04 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id tr6so8437297ieb.32 for <dbound@ietf.org>; Tue, 04 Nov 2014 13:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dcGMxn+XPCt6X2d1xbjvb4k2HsYB+228iRqo+U/QcVQ=; b=VCXoEVHkZAv/L94vWCzu6awyfKWuwB6DApOw3Pf5tg2wTyNz5q6b9oNVm92ckvabnq M0jE1AgIb9UCC82mxHoQLs2dQJGw3Ov01KTGn0TrkNqGt8tM/ZaL12WpoWcsNvgvNAfN /ZT5yeHqYM9ZGnPGK95AJG5XeFXQ7Gd4V69LI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dcGMxn+XPCt6X2d1xbjvb4k2HsYB+228iRqo+U/QcVQ=; b=HD3Gto+RR8XE22udVm+D5HD5bxZzCth415Pq2YaQQdex4DTZQQ6vfwxJhiYbs17n3S EgZk1T06fXuTLxsy4n6vve8kPwBJ1ahCVETl4DCo3MiRsd9dw92TD6ydLJ+LWtORV3et H/Y7yVoFI6UL/BryeP7iYnrHngqk/dNyvIVh9R7rxUO849XGsby8JM2NXks2kngN+YrY tBz/p2COfH6Ou4ADGvdkov6cPY5Fr+AF2hLvxZYgwsaG3Mf5yFYlEXlcoaHp62WtmjCD +vPoCR+2BTuUnrvoliBymBgR/SU1wmkPHFbPtHoZ47wzL9i+bf8UkrOadi2lGv929T6j uZfQ==
X-Gm-Message-State: ALoCoQk/jJ+7kz+6BaUQXl5QjMLB0wr+6pGRQ2I2MO0CxDbasjuc4xe0w8BvKkHeTCUyeXTvO9ip
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr861147ioo.73.1415135883951; Tue, 04 Nov 2014 13:18:03 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Tue, 4 Nov 2014 13:18:03 -0800 (PST)
In-Reply-To: <D07E8E77.5405%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org>
Date: Tue, 4 Nov 2014 16:18:03 -0500
Message-ID: <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary=001a113703b4ac180b05070eff80
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/b-G3Lp9aPH4CjC_MNrI3c_yfcAE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2014 21:18:07 -0000

--001a113703b4ac180b05070eff80
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Ed,

On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis <edward.lewis@icann.org> wrote=
:

> Thanks for writing this up. Now for the complaints. ;)
>
>
:)


> You lost me at the first sentence of 1.1.1.  (Saying that more
> dramatically than I mean to.)
>
> I don=E2=80=99t have a complete response to the paper.  In the spirit tha=
t
> provoking thoughts is better than not at this point, here are some:
>
> Fragment 1
>
> I once believed that domain names were =E2=80=9Cdot-separated alphanumeri=
c words=E2=80=9D
> but learned otherwise while working on the so-labeled clarifications on
> wild cards.  In order to being to understand how the DNS organism is
> architected, one has to view this as a tree.  And, ironically as I deal
> increasingly with non-ASCII identifiers, there=E2=80=99s no dot "on the w=
ire.=E2=80=9D
> (The root zone isn=E2=80=99t =E2=80=98.=E2=80=99, it=E2=80=99s a zero-val=
ued byte.)
>

Good point.  The introduction in this document was to provide consistent
terminology sufficient to derive a model for understanding relationships
between domain names.  There is no talk of wire format, nor is there a need
to go into those semantics, as this is all about namespace.  The
representation in this document is dot-separated labels. :)


>
> In section 1.1.2 an overly simplified view is given.  Not all domains fit
> neatly into the public and private bucket.  Some top-level-domains are no=
t
> delegation only.
>
>
For clarity, are you saying that for a single domain being public and
private are not mutually exclusive, or are you saying that top-level
domains are not all public?  I agree with the latter statement, and I'm
glad to offer more clarity in the document if it is misleading in this
regard.


> From these two comments my mind leads instantly into recommending that
> this paper attempt to describe the problem from two very different
> viewpoints.
>
> From the =E2=80=9Csystem-to-be-messed-with=E2=80=9D viewpoint, the nature=
 of the DNS data
> model as being first based on a tree structure must be respected as well
> as a clear description of the management model based on the units of
> zones.  The DNS protocol permits management of resource record sets,
> domain (nodes) as well as zones but does not permit management of a domai=
n
> (subtree).  (By the latter, I mean that DNS does not manage =E2=80=98acro=
ss' a
> zone cut.)
>

This is a valid point.  In this document I deliberately left zone cuts out
of the definitions.  The focus was on the problem of associating
namespaces, independent of zones.  Zone cut identification might be one of
the solutions considered, but even public/private boundaries need not map
consistently with zone cuts (in either direction), so the problem is about
namespace.


> From the =E2=80=9Cpeople-having-a-problem-to-solve=E2=80=9D viewpoint, wh=
ich you get to in
> 1.1.3 and 1.1.4, I prefer replacing =E2=80=9Crelated=E2=80=9D with =E2=80=
=9Cequivalent=E2=80=9D for a
> specific purpose.  (I=E2=80=99ve said that before, no need to belabor it =
now.)
> For one, you talk about a parent/child relationship but there=E2=80=99s r=
eally no
> such thing as that.  A parent delegates the child, the child knows nothin=
g
> about it=E2=80=99s parent - there=E2=80=99s no =E2=80=9Crelationship=E2=
=80=9D as far as the DNS protocol
> is concerned.
>

Yes - but let's be clear that I'm establishing terminology for discussion
of namespace (not DNS protocol) for the purposes of this document.


>
> Without giving this much thought, cross-domain relationships have been
> historically significant, more so in operations than in the protocol.  Th=
e
> co-mingling of dotCom and dotNet bear this out.
>
> I=E2=80=99m concerned about the problem set-up because, your chances of s=
olving
> the problem are better if you=E2=80=99ve properly set up the problem.
>

Agreed.


>
> Fragment 2
>
> What=E2=80=99s missing from the PSL is a discussion of the registry behin=
d the
> PSL.  Looking strictly at the list of entries and concluding we just need
> to make that work better is like saying a domain name registry is just a
> DNS operator. I.e., how can you trust that the entries are legitimate?
>

I can't tell if this is a general comment or something specific to the
document.  The problem statement document is not intended to assess the
content of the PSL--except to indicate the application of the model
described in previous sections in the paper (e.g., third paragraph of
section 3).  The intent of the document is to define the problem and
identify existing solutions.  I make no conclusions.  The question about
the effectiveness of the PSL is partially addressed with the second bullet
under "problem statement" in section 4.


> Fragment 3
>
> This is not related directly to the document, but comes from =E2=80=9CCen=
tralized
> vs. Distributed=E2=80=A6=E2=80=9D  One of the issues to think of is - how=
 do we avoid
> shared fate when we are looking for a new angle?  I.e., the DNS
> distribution model is great for doing just what the PSL wants, but placin=
g
> the PSL into the DNS is not helping.  Grossly arguing this way - if we
> expect someone to try to register a child and use it to fool people using
> the parent, what=E2=80=99s to stop the child from giving out fraudulent
> information?  (This is a handwaving argument for why
> what-ever-replaces-PSL should have some kind of separation from the DNS.)
>
> On the one hand, following the DNS tree is the best way to track who know=
s
> where the boundaries are.  On the other hand, that=E2=80=99s just the DNS
> perspective talking.  And with only one source working here, we aren=E2=
=80=99t
> making corrupting the system any harder than doing nothing at all.
>
> (I=E2=80=99m assuming that all of this is rooted in a security concern re=
lated to
> the authorization of some information to be applied/accessed/etc.
> Therefore, the talk about corrupting, fooling, fraudulent...)
>
>
The scope of the problem statement is just that--a statement of the
problem.  These are valid considerations for solutions to the problem, once
the problem has been identified and defined.


> Fragment 4
>
> It=E2=80=99s possible that here are multiple goals here, with a common th=
eme not
> clearly defined.  I see a desire to express the policies for a zone (not =
a
> domain) from the registry to a relying party.  This is one use case, not
> the only, but one use case.  This is also expressed in a DNS viewpoint.
>
> The relying party applications I can=E2=80=99t speak as well for.
>
> Fragment 5
>
> I=E2=80=99m concerned about the mention of the gTLDs as being either =E2=
=80=9Ctoo much
> detail=E2=80=9D or =E2=80=9Cnot enough detail.=E2=80=9D  The =E2=80=9Cnew=
 class=E2=80=9D of TLDs is only special
> in two respects - the rapidity that they appear and that they share a set
> of operating principles.  If by grouping them you default to grouping
> ccTLDs and legacy gTLDs, you haven=E2=80=99t made a useful categorization=
.  Until
> we know what criteria we will use to divide the top-level domains, we
> should hold off on this.
>
>
It is admittedly brief and can be fleshed out, if it needs clarity.  The
intent was not to give a discourse on the new gTLDs or to make a grouping
or categorization, but simply recognize that as gTLDs: 1) they fall into
the "unbroken public scope from the TLD" category and thus are pertinent to
the discussion of the problem (and solutions, including the PSL); 2) the
total number of gTLDs has (and will continue to) increased dramatically
with the delegation of the new gTLDs; and 3) their policies vary, just as
with previous gTLDs.  There are thus open questions of both complexity and
scalability that should be considered as the problem is defined and
solutions identified.

Cheers,
Casey

--001a113703b4ac180b05070eff80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ed,<br><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis <span dir=3D"=
ltr">&lt;<a href=3D"mailto:edward.lewis@icann.org" target=3D"_blank">edward=
.lewis@icann.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Thanks for writing this up. Now for the complaints. ;)<br>
<br></blockquote><div><br>:)<br>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
You lost me at the first sentence of 1.1.1.=C2=A0 (Saying that more<br>
dramatically than I mean to.)<br>
<br>
I don=E2=80=99t have a complete response to the paper.=C2=A0 In the spirit =
that<br>
provoking thoughts is better than not at this point, here are some:<br>
<br>
Fragment 1<br>
<br>
I once believed that domain names were =E2=80=9Cdot-separated alphanumeric =
words=E2=80=9D<br>
but learned otherwise while working on the so-labeled clarifications on<br>
wild cards.=C2=A0 In order to being to understand how the DNS organism is<b=
r>
architected, one has to view this as a tree.=C2=A0 And, ironically as I dea=
l<br>
increasingly with non-ASCII identifiers, there=E2=80=99s no dot &quot;on th=
e wire.=E2=80=9D<br>
(The root zone isn=E2=80=99t =E2=80=98.=E2=80=99, it=E2=80=99s a zero-value=
d byte.)<br></blockquote><div><br></div><div>Good point.=C2=A0 The introduc=
tion in this document was to provide consistent terminology sufficient to d=
erive a model for understanding relationships between domain names.=C2=A0 T=
here is no talk of wire format, nor is there a need to go into those semant=
ics, as this is all about namespace.=C2=A0 The representation in this docum=
ent is dot-separated labels. :)<br>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
<br>
In section 1.1.2 an overly simplified view is given.=C2=A0 Not all domains =
fit<br>
neatly into the public and private bucket.=C2=A0 Some top-level-domains are=
 not<br>
delegation only.<br>
<br></blockquote><div><br></div><div>For clarity, are you saying that for a=
 single domain being public and private are not mutually exclusive, or are =
you saying that top-level domains are not all public?=C2=A0 I agree with th=
e latter statement, and I&#39;m glad to offer more clarity in the document =
if it is misleading in this regard.<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
>From these two comments my mind leads instantly into recommending that<br>
this paper attempt to describe the problem from two very different<br>
viewpoints.<br>
<br>
>From the =E2=80=9Csystem-to-be-messed-with=E2=80=9D viewpoint, the nature o=
f the DNS data<br>
model as being first based on a tree structure must be respected as well<br=
>
as a clear description of the management model based on the units of<br>
zones.=C2=A0 The DNS protocol permits management of resource record sets,<b=
r>
domain (nodes) as well as zones but does not permit management of a domain<=
br>
(subtree).=C2=A0 (By the latter, I mean that DNS does not manage =E2=80=98a=
cross&#39; a<br>
zone cut.)<br></blockquote><div><br></div><div>This is a valid point.=C2=A0=
 In this document I deliberately left zone cuts out of the definitions.=C2=
=A0 The focus was on the problem of associating namespaces, independent of =
zones.=C2=A0 Zone cut identification might be one of the solutions consider=
ed, but even public/private boundaries need not map consistently with zone =
cuts (in either direction), so the problem is about namespace.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>From the =E2=80=9Cpeople-having-a-problem-to-solve=E2=80=9D viewpoint, whic=
h you get to in<br>
1.1.3 and 1.1.4, I prefer replacing =E2=80=9Crelated=E2=80=9D with =E2=80=
=9Cequivalent=E2=80=9D for a<br>
specific purpose.=C2=A0 (I=E2=80=99ve said that before, no need to belabor =
it now.)<br>
For one, you talk about a parent/child relationship but there=E2=80=99s rea=
lly no<br>
such thing as that.=C2=A0 A parent delegates the child, the child knows not=
hing<br>
about it=E2=80=99s parent - there=E2=80=99s no =E2=80=9Crelationship=E2=80=
=9D as far as the DNS protocol<br>
is concerned.<br></blockquote><div><br></div><div>Yes - but let&#39;s be cl=
ear that I&#39;m establishing terminology for discussion of namespace (not =
DNS protocol) for the purposes of this document.<br>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
<br>
Without giving this much thought, cross-domain relationships have been<br>
historically significant, more so in operations than in the protocol.=C2=A0=
 The<br>
co-mingling of dotCom and dotNet bear this out.<br>
<br>
I=E2=80=99m concerned about the problem set-up because, your chances of sol=
ving<br>
the problem are better if you=E2=80=99ve properly set up the problem.<br></=
blockquote><div><br></div><div>Agreed.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
Fragment 2<br>
<br>
What=E2=80=99s missing from the PSL is a discussion of the registry behind =
the<br>
PSL.=C2=A0 Looking strictly at the list of entries and concluding we just n=
eed<br>
to make that work better is like saying a domain name registry is just a<br=
>
DNS operator. I.e., how can you trust that the entries are legitimate?<br><=
/blockquote><div><br>I can&#39;t tell if this is a general comment or somet=
hing specific to the document.=C2=A0 The problem statement document is not =
intended to assess the content of the PSL--except to indicate the applicati=
on of the model described in previous sections in the paper (e.g., third pa=
ragraph of section 3).=C2=A0 The intent of the document is to define the pr=
oblem and identify existing solutions.=C2=A0 I make no conclusions.=C2=A0 T=
he question about the effectiveness of the PSL is partially addressed with =
the second bullet under &quot;problem statement&quot; in section 4.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Fragment 3<br>
<br>
This is not related directly to the document, but comes from =E2=80=9CCentr=
alized<br>
vs. Distributed=E2=80=A6=E2=80=9D=C2=A0 One of the issues to think of is - =
how do we avoid<br>
shared fate when we are looking for a new angle?=C2=A0 I.e., the DNS<br>
distribution model is great for doing just what the PSL wants, but placing<=
br>
the PSL into the DNS is not helping.=C2=A0 Grossly arguing this way - if we=
<br>
expect someone to try to register a child and use it to fool people using<b=
r>
the parent, what=E2=80=99s to stop the child from giving out fraudulent<br>
information?=C2=A0 (This is a handwaving argument for why<br>
what-ever-replaces-PSL should have some kind of separation from the DNS.)<b=
r>
<br>
On the one hand, following the DNS tree is the best way to track who knows<=
br>
where the boundaries are.=C2=A0 On the other hand, that=E2=80=99s just the =
DNS<br>
perspective talking.=C2=A0 And with only one source working here, we aren=
=E2=80=99t<br>
making corrupting the system any harder than doing nothing at all.<br>
<br>
(I=E2=80=99m assuming that all of this is rooted in a security concern rela=
ted to<br>
the authorization of some information to be applied/accessed/etc.<br>
Therefore, the talk about corrupting, fooling, fraudulent...)<br>
<br></blockquote><div><br></div><div>The scope of the problem statement is =
just that--a statement of the problem.=C2=A0 These are valid considerations=
 for solutions to the problem, once the problem has been identified and def=
ined.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
Fragment 4<br>
<br>
It=E2=80=99s possible that here are multiple goals here, with a common them=
e not<br>
clearly defined.=C2=A0 I see a desire to express the policies for a zone (n=
ot a<br>
domain) from the registry to a relying party.=C2=A0 This is one use case, n=
ot<br>
the only, but one use case.=C2=A0 This is also expressed in a DNS viewpoint=
.<br>
<br>
The relying party applications I can=E2=80=99t speak as well for.<br>
<br>
Fragment 5<br>
<br>
I=E2=80=99m concerned about the mention of the gTLDs as being either =E2=80=
=9Ctoo much<br>
detail=E2=80=9D or =E2=80=9Cnot enough detail.=E2=80=9D=C2=A0 The =E2=80=9C=
new class=E2=80=9D of TLDs is only special<br>
in two respects - the rapidity that they appear and that they share a set<b=
r>
of operating principles.=C2=A0 If by grouping them you default to grouping<=
br>
ccTLDs and legacy gTLDs, you haven=E2=80=99t made a useful categorization.=
=C2=A0 Until<br>
we know what criteria we will use to divide the top-level domains, we<br>
should hold off on this.<br>
<div><div><br></div></div></blockquote><div><br></div><div>It is admittedly=
 brief and can be fleshed out, if it needs clarity.=C2=A0 The intent was no=
t to give a discourse on the new gTLDs or to make a grouping or categorizat=
ion, but simply recognize that as gTLDs: 1) they fall into the &quot;unbrok=
en public scope from the TLD&quot; category and thus are pertinent to the d=
iscussion of the problem (and solutions, including the PSL); 2) the total n=
umber of gTLDs has (and will continue to) increased dramatically with the d=
elegation of the new gTLDs; and 3) their policies vary, just as with previo=
us gTLDs.=C2=A0 There are thus open questions of both complexity and scalab=
ility that should be considered as the problem is defined and solutions ide=
ntified.<br><br></div><div>Cheers,<br></div><div>Casey<br></div></div></div=
></div></div>

--001a113703b4ac180b05070eff80--


From nobody Tue Nov  4 20:45:05 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3311A6EF9 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 20:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7quv0BuJ8rC5 for <dbound@ietfa.amsl.com>; Tue,  4 Nov 2014 20:44:57 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8781A87B1 for <dbound@ietf.org>; Tue,  4 Nov 2014 20:44:57 -0800 (PST)
Received: (qmail 86821 invoked from network); 5 Nov 2014 04:44:55 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Nov 2014 04:44:55 -0000
Date: 5 Nov 2014 04:44:33 -0000
Message-ID: <20141105044433.75806.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAEKtLiRawTO+42=OqqA0AwCTr=iJTq2FTYO-scNJpAHOxQ0=Dg@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/b226Vds_DpFy_ttmGrsQpd_Bhf8
Cc: casey@deccio.net
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 04:45:00 -0000

>Update: There was a venue conflict with the Thursday time, so I'm proposing
>Tuesday morning in its place.

I could do Tuesday morning.

R's,
John


From nobody Wed Nov  5 02:22:53 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D9C1A884E for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 02:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.199
X-Spam-Level: *
X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwhUD0vET2_u for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 02:22:50 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05F81A0470 for <dbound@ietf.org>; Wed,  5 Nov 2014 02:22:49 -0800 (PST)
Received: from [81.187.243.93] (port=51950 helo=[192.168.0.103]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1Xlxji-0008MI-Of; Wed, 05 Nov 2014 10:22:47 +0000
Message-ID: <5459FA73.40208@mozilla.org>
Date: Wed, 05 Nov 2014 10:22:43 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>	<54591324.3040803@mozilla.org> <CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com>
In-Reply-To: <CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/NwxNxGfsNK9tM1U3bcz_CdLUO5w
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 10:22:51 -0000

On 04/11/14 19:57, Casey Deccio wrote:
> Of course, future modifications make some of the remarks below moot, but
> just to be sure we're on the same page...
> 
>     The first of these rules suggests that foo.example is private, the
>     second that it is public
> 
> Well, technically the first rule only indicates the example is public. 
> Whether or not foo.example is effectively private depends on the
> complete algorithm, not the stand-alone entry, correct?

The PSL is both a list an an algorithm for interpreting it. One makes no
sense without the other. (People may choose to use alternative
algorithms, but they are entirely responsible for the results!)

Aargh! Clash of use of "foo"! I forgot the third example used foo.

Let me rewrite my comment:

The first of these rules suggests that fred.example is private, the
second that it is public.

Your Table 2 is therefore wrong, because the
PSL algorithm states that the longest matching rule applies, and so
fred.example is public, not private (by the second rule).
https://publicsuffix.org/list/ has the algorithm.

Does that make more sense?

My point is a clash between the first and second examples; I didn't
intend to drag the third one in.

>     It's not as simple as that. Google is allowed a cert for
>     *.blogspot.com <http://blogspot.com>,
>     but by your definitions, foo.blogspot.com <http://foo.blogspot.com>
>     and bar.blogspot.com <http://bar.blogspot.com> are not
>     under the same control. This is why the PSL is split into two sections -
>     "ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)
> 
> 
> In the document I've defined the terms more generically.  If I
> understand correctly, "ICANN DOMAINS" translates to what are referred to
> in the document as "public domains in unbroken public scope", and
> "PRIVATE DOMAINS" translates to names "under islands of private scope"
> (referred to in the third paragraph of Section 3 and opening paragraph
> of Section 4). 

Ah, yes. I guess my point then is that this section doesn't seem to take
account of that distinction?

> In the document I think you're suggesting that I note that (at least in
> the case of the SSL wildcard) the different types of public domains
> might be treated differently.

Yes.

> The sentence is a bit cryptic.  But what it means is the following. 
> Given the following two domains, both "private" as far as PSL processing
> is concerned:
> 
> sub.foo.example
> foo.example
> 
> Are the two "related"?  The PSL cannot tell us.  It can only tell us
> (assuming entries are correct) that there is no public/private boundary
> between them.

I guess the hierarchical understanding of "related" is somewhat implicit
in the way the PSL works and the defined algorithm... but yes, I guess
the PSL does not have an isRelated() call.

Gerv


From nobody Wed Nov  5 06:21:59 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865BA1A890F for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waGkqmi8X8PX for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:21:54 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D811A1B46 for <dbound@ietf.org>; Wed,  5 Nov 2014 06:21:54 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 06:21:50 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 06:21:50 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AA==
Date: Wed, 5 Nov 2014 14:21:49 +0000
Message-ID: <D07F986D.544A%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com>
In-Reply-To: <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [68.98.142.232]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498024106_4040410"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/wjAYTgojaSKw8FPtTertPfsqzl4
Cc: Casey Deccio <casey@deccio.net>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 14:21:57 -0000

--B_3498024106_4040410
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Instead of being specific, I=E2=80=99ll offer a general set of comments.  I think
Casey and John have captured the state of the group, no argument with
that, so my observations are about where we are and not the specifics in
the paper.

Perhaps a mistake we are making is talking (so much) about the DNS
perspective.  Coming from the remark that zone cuts were avoided because
we are ruling out zone cut identification as a goal: first, I agree this
isn=E2=80=99t about zone cut identification.  But once we start analyzing the DNS
side of this, we need to be accurate and faithful to the DNS architecture
or we will screw this up - as in how one application screwed up an
understanding of how DNS wild cards work resulting in a mismatch in what
=E2=80=98match=E2=80=99 means.  (I should cite the specific instance, it has been
mentioned on the list, but I just can=E2=80=99t find it now.)  That said, I=E2=80=99d
rather see the group =E2=80=9Cignore=E2=80=9D the DNS for the moment and concentrate on
what =E2=80=9Cservice=E2=80=9D needs to be defined.

I=E2=80=99m willing to go as far as recognizing that there are identifiers in pla=
y
represented as domain names.  Beyond that, such as the fact that they are
hierarchical and rendered in a format that makes them look more like a
route than a name, isn=E2=80=99t that important.  In fact I think the paper spend=
s
a lot of words describing this and then saying this isn=E2=80=99t what is
important.  IMHO, it comes to taking two identifiers (represented as
domain names) and deciding if, for some operation they are to be
considered the same/treated equally, or (I=E2=80=99ll say it again) equivalent.

The material related to PSL falls into the same boat.  The PSL is a first
stab at solving some part of the still somewhat hazy problem.  It is the
crutch used to handle the first use case - the so-called cookies problem,
better known (again, in my opinion) as the common origin problem.  The PSL
and the DNS here are more =E2=80=9Clay of the land=E2=80=9D than part of the problem
statement.  These are two things we have to work with, like unfinished and
unset modeling clay.

Because of that, take my comments before with a grain of salt.  Perhaps we
need to go up a level and not down a level (as I was drilling into).

But on to the discussion of whether upper level domains are exculsive-or
public or private.  The problem I have is that in making such a divide (or
any exclusive-or divide) if there are corner cases you=E2=80=99ll pay for it
later.  I=E2=80=99m not sold that one can cleanly divide the domains, if so,
whether it is meaningful - and I wretch in my seat because these are
really zones, not domains.  E.g., dotUS is a mix of delegations and data.
Perhaps you can call US public (for the most part it is), but it has some
private elements.  And E.g., compare how dotUK has been run (until the
recent policy change) versus CO.UK.  dotUK is essentially private (and
signed with NSEC to boot) but CO.UK. would be public.

I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on why we are labeling
domains as public or private.

Looking forward to getting to a problem statement.  And I do believe that
there may be more than one problem to solve, which is why we seem to be
going (if that can be said) in circles.

-----Original Message-----
From: Casey Deccio <casey@deccio.net>
Date: Tuesday, November 4, 2014 at 16:18
To: Edward Lewis <edward.lewis@icann.org>
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>Hi Ed,
>
>On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis
><edward.lewis@icann.org> wrote:
>
>Thanks for writing this up. Now for the complaints. ;)
>
>
>
>
>:)
>=20
>
>
>You lost me at the first sentence of 1.1.1.  (Saying that more
>dramatically than I mean to.)
>
>I don=E2=80=99t have a complete response to the paper.  In the spirit that
>provoking thoughts is better than not at this point, here are some:
>
>Fragment 1
>
>I once believed that domain names were =E2=80=9Cdot-separated alphanumeric words=
=E2=80=9D
>but learned otherwise while working on the so-labeled clarifications on
>wild cards.  In order to being to understand how the DNS organism is
>architected, one has to view this as a tree.  And, ironically as I deal
>increasingly with non-ASCII identifiers, there=E2=80=99s no dot "on the wire.=E2=80=9D
>(The root zone isn=E2=80=99t =E2=80=98.=E2=80=99, it=E2=80=99s a zero-valued byte.)
>
>
>
>
>Good point.  The introduction in this document was to provide consistent
>terminology sufficient to derive a model for understanding relationships
>between domain names.  There is no talk of wire format, nor is there a
>need to go into those semantics, as
> this is all about namespace.  The representation in this document is
>dot-separated labels. :)
>=20
>
>
>
>In section 1.1.2 an overly simplified view is given.  Not all domains fit
>neatly into the public and private bucket.  Some top-level-domains are not
>delegation only.
>
>
>
>
>
>For clarity, are you saying that for a single domain being public and
>private are not mutually exclusive, or are you saying that top-level
>domains are not all public?  I agree with the latter statement, and I'm
>glad to offer more clarity in the document
> if it is misleading in this regard.
>
>=20
>
>From these two comments my mind leads instantly into recommending that
>this paper attempt to describe the problem from two very different
>viewpoints.
>
>From the =E2=80=9Csystem-to-be-messed-with=E2=80=9D viewpoint, the nature of the DNS d=
ata
>model as being first based on a tree structure must be respected as well
>as a clear description of the management model based on the units of
>zones.  The DNS protocol permits management of resource record sets,
>domain (nodes) as well as zones but does not permit management of a domain
>(subtree).  (By the latter, I mean that DNS does not manage =E2=80=98across' a
>zone cut.)
>
>
>
>
>This is a valid point.  In this document I deliberately left zone cuts
>out of the definitions.  The focus was on the problem of associating
>namespaces, independent of zones.  Zone cut identification might be one
>of the solutions considered, but even public/private
> boundaries need not map consistently with zone cuts (in either
>direction), so the problem is about namespace.
>
>
>
>
>From the =E2=80=9Cpeople-having-a-problem-to-solve=E2=80=9D viewpoint, which you get t=
o in
>1.1.3 and 1.1.4, I prefer replacing =E2=80=9Crelated=E2=80=9D with =E2=80=9Cequivalent=E2=80=9D fo=
r a
>specific purpose.  (I=E2=80=99ve said that before, no need to belabor it now.)
>For one, you talk about a parent/child relationship but there=E2=80=99s really n=
o
>such thing as that.  A parent delegates the child, the child knows nothing
>about it=E2=80=99s parent - there=E2=80=99s no =E2=80=9Crelationship=E2=80=9D as far as the DNS pr=
otocol
>is concerned.
>
>
>
>
>Yes - but let's be clear that I'm establishing terminology for discussion
>of namespace (not DNS protocol) for the purposes of this document.
>=20
>
>
>
>Without giving this much thought, cross-domain relationships have been
>historically significant, more so in operations than in the protocol.  The
>co-mingling of dotCom and dotNet bear this out.
>
>I=E2=80=99m concerned about the problem set-up because, your chances of solving
>the problem are better if you=E2=80=99ve properly set up the problem.
>
>
>
>
>Agreed.
>=20
>
>
>
>Fragment 2
>
>What=E2=80=99s missing from the PSL is a discussion of the registry behind the
>PSL.  Looking strictly at the list of entries and concluding we just need
>to make that work better is like saying a domain name registry is just a
>DNS operator. I.e., how can you trust that the entries are legitimate?
>
>
>
>I can't tell if this is a general comment or something specific to the
>document.  The problem statement document is not intended to assess the
>content of the PSL--except to indicate the application of the model
>described in previous sections in the paper (e.g.,
> third paragraph of section 3).  The intent of the document is to define
>the problem and identify existing solutions.  I make no conclusions.  The
>question about the effectiveness of the PSL is partially addressed with
>the second bullet under "problem statement"
> in section 4.
>
>
>
>
>Fragment 3
>
>This is not related directly to the document, but comes from =E2=80=9CCentralize=
d
>vs. Distributed=E2=80=A6=E2=80=9D  One of the issues to think of is - how do we avoid
>shared fate when we are looking for a new angle?  I.e., the DNS
>distribution model is great for doing just what the PSL wants, but placing
>the PSL into the DNS is not helping.  Grossly arguing this way - if we
>expect someone to try to register a child and use it to fool people using
>the parent, what=E2=80=99s to stop the child from giving out fraudulent
>information?  (This is a handwaving argument for why
>what-ever-replaces-PSL should have some kind of separation from the DNS.)
>
>On the one hand, following the DNS tree is the best way to track who knows
>where the boundaries are.  On the other hand, that=E2=80=99s just the DNS
>perspective talking.  And with only one source working here, we aren=E2=80=99t
>making corrupting the system any harder than doing nothing at all.
>
>(I=E2=80=99m assuming that all of this is rooted in a security concern related t=
o
>the authorization of some information to be applied/accessed/etc.
>Therefore, the talk about corrupting, fooling, fraudulent...)
>
>
>
>
>
>The scope of the problem statement is just that--a statement of the
>problem.  These are valid considerations for solutions to the problem,
>once the problem has been identified and defined.
>
>=20
>
>Fragment 4
>
>It=E2=80=99s possible that here are multiple goals here, with a common theme not
>clearly defined.  I see a desire to express the policies for a zone (not a
>domain) from the registry to a relying party.  This is one use case, not
>the only, but one use case.  This is also expressed in a DNS viewpoint.
>
>The relying party applications I can=E2=80=99t speak as well for.
>
>Fragment 5
>
>I=E2=80=99m concerned about the mention of the gTLDs as being either =E2=80=9Ctoo much
>detail=E2=80=9D or =E2=80=9Cnot enough detail.=E2=80=9D  The =E2=80=9Cnew class=E2=80=9D of TLDs is only=
 special
>in two respects - the rapidity that they appear and that they share a set
>of operating principles.  If by grouping them you default to grouping
>ccTLDs and legacy gTLDs, you haven=E2=80=99t made a useful categorization.  Unti=
l
>we know what criteria we will use to divide the top-level domains, we
>should hold off on this.
>
>
>
>
>
>
>
>It is admittedly brief and can be fleshed out, if it needs clarity.  The
>intent was not to give a discourse on the new gTLDs or to make a grouping
>or categorization, but simply recognize that as gTLDs: 1) they fall into
>the "unbroken public scope from
> the TLD" category and thus are pertinent to the discussion of the
>problem (and solutions, including the PSL); 2) the total number of gTLDs
>has (and will continue to) increased dramatically with the delegation of
>the new gTLDs; and 3) their policies vary, just
> as with previous gTLDs.  There are thus open questions of both
>complexity and scalability that should be considered as the problem is
>defined and solutions identified.
>
>
>Cheers,
>
>Casey
>
>
>
>
>

--B_3498024106_4040410
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSh0iLBUGWbC5IrTwS6
3RNcA+ucrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDUxNDIxNDZaMA0GCSqGSIb3DQEBAQUABIIBAGfayT4LQz75/Jo3LJt1xJnroTWsK15S3TZU
9WpEb4eLqUppN7wXpzVbChmKpY0MHs7yvyhy0CptnsjKRBjwOhcgEoPAcCTiYCtGrcbzQ+6X
P0WIHtgRnJraARGJtEm80hNiIr3HJ/PQ8VK2NjDcN36Nxz1a3WOTaGeuvgjM4XUMv+9gIj9W
xEWfNIEnkRcXZFX9nx/HLmalpkLAyfClzt2eQ5onC4xNZ14DusdE52ereCmpPmNBZsOS/PB3
eD3y81vnfAeY2zoRMxA6K9EnjLaBzIsQQ3kj8FazzqWeYyS1vCe6YN4we/BHIbu24Iodwv30
aapouYxHEAn4BQC4cgE=

--B_3498024106_4040410--


From nobody Wed Nov  5 06:36:36 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC01A892E for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:36:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiV5PjmYV4ZU for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:36:33 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE2D1A1B46 for <dbound@ietf.org>; Wed,  5 Nov 2014 06:36:33 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 486C68A031 for <dbound@ietf.org>; Wed,  5 Nov 2014 14:36:32 +0000 (UTC)
Date: Wed, 5 Nov 2014 09:36:30 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141105143630.GD30379@mx1.yitter.info>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D07F986D.544A%edward.lewis@icann.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/RhnvEn0nzj9gD3_hL6AMAuLLPEQ
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 14:36:34 -0000

On Wed, Nov 05, 2014 at 02:21:49PM +0000, Edward Lewis wrote:
> 
> I guess what I’m saying is that I’m not so clear on why we are labeling
> domains as public or private.

Your concern is precisely why, in my previous stabs at this, I have
attempted to avoid that.  It's the wrong classification, IMO, even if
it's a useful rule of thumb sometimes; and too much confusion has
resulted from trying to use it.

Instead, we should be looking for a way of grouping identifiers
according to other classifications.  The motivating stuff in the
earlier I-Ds I wrote or worked on with Jeff is there to explain why
the DNS hierarchy is _not_ the right classification, despite the
attempts in the past to use it.  

Unfortunately, to my way of thinking, people who have running code
that is already based on the faulty reading of the hierarchy are
unlikely to change that enough to work with new arbitrary groupings.
Moreover, there's the additional problem that allowing arbitrary links
out of hierarchy will potentially explode the data that clients have
to pay attention to, and nobody is enthusiastic about that.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Wed Nov  5 06:40:15 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0D1A1B31 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU3bAfaEv5Rx for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:40:12 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38741A1B55 for <dbound@ietf.org>; Wed,  5 Nov 2014 06:40:11 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn18so8819963igb.1 for <dbound@ietf.org>; Wed, 05 Nov 2014 06:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1q0ucZ7Dz2GskRK1iks4Fqlvsyv+YNa4K77xd67zSew=; b=Qx9oZeZzhTCM2flvFNqNddEpkZFPQn2gOje3PllrMhcYR4mptYoVrctdVbeYxg4mE/ zqYwNfTa0Otzrb6WY86Um5VXaQhuaKflx95FP7d54OBkIi3vjaM6562goZHDacfqQwMT b6WO4/14IKK/2CuFrdYb2vb7SEtuTfGlwflAY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1q0ucZ7Dz2GskRK1iks4Fqlvsyv+YNa4K77xd67zSew=; b=UzA8InyzWo3hdG6WLa306nugWTUPkvt2LpFDeAupZxDj501vn8Ellh9UuTzcFiNXfJ XxhHnTjuHAsitYF/0uwMcB9LM1zPg0k75MxrOI64UN0MfrCt9475LqfCb//ypfC7gZQp WPJTYI55erPglL2h0gOVoK2PtVR/cHQRzegaeTm6gcDc0g40pyjISL8QDI8s24MADAsE mobW6tg/56Ye6PTleDFdSToMuuglwsedMN42obsRsj8q2f9pkEXMKHsApJzqXHP42ZIp fY5KZTnNsV7rwxukEgl4b6s2BlWHvkHGXRYq1MBKVQ3tjXJ61Z7FF/O4qaKbYP6hL3bk XNoQ==
X-Gm-Message-State: ALoCoQlk3NNHaW+W6UpPSp/Hj4LMqfQk9vZaw/qSmP64B+P9UeeVQX8MDUNsmo/XU+La68qwnCqy
MIME-Version: 1.0
X-Received: by 10.50.79.166 with SMTP id k6mr32001475igx.0.1415198404223; Wed, 05 Nov 2014 06:40:04 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 06:40:04 -0800 (PST)
In-Reply-To: <5459FA73.40208@mozilla.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <54591324.3040803@mozilla.org> <CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com> <5459FA73.40208@mozilla.org>
Date: Wed, 5 Nov 2014 09:40:04 -0500
Message-ID: <CAEKtLiTOcUAzRx6TuJGKKWecGwW5PijPS2CCmZ5Qh61TCeW2_Q@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Gervase Markham <gerv@mozilla.org>
Content-Type: multipart/alternative; boundary=089e013a114e2be83205071d8e93
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Ezsfi0kkJQMM0FMU8UKUhjWPzNE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 14:40:14 -0000

--089e013a114e2be83205071d8e93
Content-Type: text/plain; charset=UTF-8

Hi Gerv,

On Wed, Nov 5, 2014 at 5:22 AM, Gervase Markham <gerv@mozilla.org> wrote:

> The PSL is both a list an an algorithm for interpreting it. One makes no
> sense without the other. (People may choose to use alternative
> algorithms, but they are entirely responsible for the results!)
>
>
I completely agree.


> Aargh! Clash of use of "foo"! I forgot the third example used foo.
>
>
:)


> Let me rewrite my comment:
>
> The first of these rules suggests that fred.example is private,


To your previous point that the list and the algorithm make no sense
without each other, the inference that "fred.example" is private cannot be
made from the single list entry; according to the algorithm, the name in
question must be matched against all rules, and "the prevailing rule is the
one with the most labels" [1].  In other words, "fred.example" does not
ultimately match "example", but rather "*.example".  Thus it is (only)
considered public.


> the second that it is public.
>

> Your Table 2 is therefore wrong, because the
> PSL algorithm states that the longest matching rule applies, and so
> fred.example is public, not private (by the second rule).
> https://publicsuffix.org/list/ has the algorithm.
>
>
While "fred.example" isn't an example from the document, "bar.example" has
the same properties as "fred.example" would (i.e., they both match the
wildcard) and "bar.example" is in the table, having public scope, as you
and I would expect.  I'm not sure, therefore, how Table 2 is wrong.


> Does that make more sense?
>
> My point is a clash between the first and second examples; I didn't
> intend to drag the third one in.
>

I'm wondering if that is the confusion with the most recent point as well.
Is it possible that you were looking at the entry "foo.example" in Table 2
and forgetting that it matched the wildcard exception (i.e., was not in the
same category as "fred.example" and "bar.example"), just as the wildcard
exception for "foo.example" was overlooked when you contrived your own
example (and they ultimately clashed)?

On a related point, there was some question as to whether entries for
"example" and "*.example" were both useful in the list.  You indicated that
they were not (and I can see that is the case in the current PSL, both by
entries and by testing), and my initial response was agreement.  However,
it is not clear to me from the specified algorithm that "*.example" implies
"example".  If that implication is intentional, then it seems inconsistent
with the specification as I read it: "The wildcard character * (asterisk)
matches any valid sequence of characters in a hostname part" and "Wildcards
may only be used to wildcard an entire level" [1].

Whether or not the implication is intended, it might be useful to allow the
names to be considered separately--because of the question of whether the
name (i.e., the "parent" of the wildcard) itself is public or private,
which is distinct from whether a name matching the wildcard is public.

> In the document I've defined the terms more generically.  If I
> > understand correctly, "ICANN DOMAINS" translates to what are referred to
> > in the document as "public domains in unbroken public scope", and
> > "PRIVATE DOMAINS" translates to names "under islands of private scope"
> > (referred to in the third paragraph of Section 3 and opening paragraph
> > of Section 4).
>
> Ah, yes. I guess my point then is that this section doesn't seem to take
> account of that distinction?
>
>
Okay, I'll clarify.


> I guess the hierarchical understanding of "related" is somewhat implicit
> in the way the PSL works and the defined algorithm... but yes, I guess
> the PSL does not have an isRelated() call.
>

It might seem as though nits are being picked here, but the idea behind the
problem statement is to understand the abilities and limitations of

[1] https://publicsuffix.org/list/

--089e013a114e2be83205071d8e93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Gerv,<br><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Nov 5, 2014 at 5:22 AM, Gervase Markham <span dir=
=3D"ltr">&lt;<a href=3D"mailto:gerv@mozilla.org" target=3D"_blank">gerv@moz=
illa.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">The PSL is both a list an an algorithm for interpreting it. One =
makes no<br>
sense without the other. (People may choose to use alternative<br>
algorithms, but they are entirely responsible for the results!)<br>
<br></blockquote><div><br></div><div>I completely agree.<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
Aargh! Clash of use of &quot;foo&quot;! I forgot the third example used foo=
.<br>
<br></blockquote><div><br>:)<br>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
Let me rewrite my comment:<br>
<br>
The first of these rules suggests that fred.example is private,</blockquote=
><div><br>To your previous point that the list and the algorithm make no se=
nse=20
without each other, the inference that &quot;fred.example&quot; is private =
cannot be
 made from the single list entry; according to the algorithm, the name in=
=20
question must be matched against all rules, and &quot;the prevailing rule i=
s=20
the one with the most labels&quot; [1].=C2=A0 In other words, &quot;fred.ex=
ample&quot; does=20
not ultimately match &quot;example&quot;, but rather &quot;*.example&quot;.=
=C2=A0 Thus it is (only) considered public.</div><div>=C2=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">the second that it is public.=
=C2=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=3D""><br>
Your Table 2 is therefore wrong, because the<br>
PSL algorithm states that the longest matching rule applies, and so<br>
</span>fred.example is public, not private (by the second rule).<br>
<span class=3D""><a href=3D"https://publicsuffix.org/list/" target=3D"_blan=
k">https://publicsuffix.org/list/</a> has the algorithm.<br>
<br></span></blockquote><div><br></div><div>While &quot;fred.example&quot; =
isn&#39;t an example from the document, &quot;bar.example&quot; has the sam=
e properties as &quot;fred.example&quot; would (i.e., they both match the w=
ildcard) and &quot;bar.example&quot; is in the table, having public scope, =
as you and I would expect.=C2=A0 I&#39;m not sure, therefore, how Table 2 i=
s wrong.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><span class=3D"">
</span>Does that make more sense?<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My point is a clash between the first and second examples; I didn&#39;t<br>
intend to drag the third one in.<span class=3D""><br></span></blockquote><d=
iv><br></div><div>I&#39;m wondering if that is the confusion with the most =
recent point as well.=C2=A0 Is it possible that you were looking at the ent=
ry &quot;foo.example&quot; in Table 2 and forgetting that it matched the wi=
ldcard exception (i.e., was not in the same category as &quot;fred.example&=
quot; and &quot;bar.example&quot;), just as the wildcard exception for &quo=
t;foo.example&quot; was overlooked when you contrived your own example (and=
 they ultimately clashed)?<br><br></div><div>On a related point, there was =
some question as to whether entries for &quot;example&quot; and &quot;*.exa=
mple&quot; were both useful in the list.=C2=A0 You indicated that they were=
 not (and I can see that is the case in the current PSL, both by entries an=
d by testing), and my initial response was agreement.=C2=A0 However, it is =
not clear to me from the specified algorithm that &quot;*.example&quot; imp=
lies &quot;example&quot;.=C2=A0 If that implication is intentional, then it=
 seems inconsistent with the specification as I read it: &quot;The wildcard=
 character * (asterisk) matches any valid sequence of characters in a hostn=
ame part&quot; and &quot;Wildcards may only be used to wildcard an entire l=
evel&quot; [1].<br><br>Whether or not the implication is intended, it might=
 be useful to allow the names to be considered separately--because of the q=
uestion of whether the name (i.e., the &quot;parent&quot; of the wildcard) =
itself is public or private, which is distinct from whether a name matching=
 the wildcard is public.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><span class=3D"">
&gt; In the document I&#39;ve defined the terms more generically.=C2=A0 If =
I<br>
&gt; understand correctly, &quot;ICANN DOMAINS&quot; translates to what are=
 referred to<br>
&gt; in the document as &quot;public domains in unbroken public scope&quot;=
, and<br>
&gt; &quot;PRIVATE DOMAINS&quot; translates to names &quot;under islands of=
 private scope&quot;<br>
&gt; (referred to in the third paragraph of Section 3 and opening paragraph=
<br>
&gt; of Section 4).<br>
<br>
</span>Ah, yes. I guess my point then is that this section doesn&#39;t seem=
 to take<br>
account of that distinction?<br>
<span class=3D""><br></span></blockquote><div><br></div><div>Okay, I&#39;ll=
 clarify.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><span class=3D"">
</span>I guess the hierarchical understanding of &quot;related&quot; is som=
ewhat implicit<br>
in the way the PSL works and the defined algorithm... but yes, I guess<br>
the PSL does not have an isRelated() call.<br></blockquote><div><br></div><=
div>It might seem as though nits are being picked here, but the idea behind=
 the problem statement is to understand the abilities and limitations of <b=
r></div><div><br></div></div>[1] <a href=3D"https://publicsuffix.org/list/"=
>https://publicsuffix.org/list/</a><br></div></div></div>

--089e013a114e2be83205071d8e93--


From nobody Wed Nov  5 06:52:05 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD271ABD39 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrZQevZXQxIH for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 06:52:02 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6993F1AC413 for <dbound@ietf.org>; Wed,  5 Nov 2014 06:52:02 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 06:51:59 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 06:51:59 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAV+8A//+wfYA=
Date: Wed, 5 Nov 2014 14:51:59 +0000
Message-ID: <D07FA213.5456%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org> <20141105143630.GD30379@mx1.yitter.info>
In-Reply-To: <20141105143630.GD30379@mx1.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [68.98.142.232]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498025915_4181182"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/0SVJhhzmJnR5RoUO3pw7RZTYrtc
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 14:52:04 -0000

--B_3498025915_4181182
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

As a historical note:

-----Original Message-----
From: Andrew Sullivan <ajs@anvilwalrusden.com>
Date: Wednesday, November 5, 2014 at 9:36
To: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>
>Moreover, there's the additional problem that allowing arbitrary links
>out of hierarchy will potentially explode the data that clients have
>to pay attention to, and nobody is enthusiastic about that.

Which is why (section 2.7 of) RFC 3008 was written as an update to RFC
2535.

I.e., we designed the DNSSEC signatures to follow =E2=80=9Carbitrary links out of
the hierarchy=E2=80=9D. Despite some research into that, we couldn=E2=80=99t make it
happen.  We couldn=E2=80=99t, for one, come up with a workable language to expres=
s
a policy of who can sign for what.  I.e., we couldn=E2=80=99t come up with a way
to say that two owners of KEY sets were equivalent when it came to
establishing trust in the signature.

--B_3498025915_4181182
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR1yb8SyWFFgkmviB6k
3QCCYl+F9DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDUxNDUxNTVaMA0GCSqGSIb3DQEBAQUABIIBAKi3rB2Bxk0a8+P1Q4siv5X0+aJFrvQMkqqE
Hu6jv5wW3lmrJ4rsFUaZnExr2DPuM3ex0dUV0EK+0ogF/G7SMLGRLPvKA/0UK3qHFU1hq8oT
LtYWG1jYHU+2t22zRwcnqNrCrakIEPK4Z2ylyhefvsi3MEsOGTxEZiZOT9wMzKHtgzx1fqh4
+NoQyVIQGpP6rMe5W70wERVfb0jsjy9tMfPQubkXixLMHj0/18haaWzeUMBEZ8mklnHW9ZpC
owWfKUrIB1BCZPVUS3PiXHLM1tqaxP3yT/YQWol07K/fbWjzFHhx2u7QQ8qXt12A1ZO2ewud
iC+zSrYipF3ee8SJilk=

--B_3498025915_4181182--


From nobody Wed Nov  5 07:25:21 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9D1A894F for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 07:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWz-p4KkEl1o for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 07:25:18 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DDE1A892C for <dbound@ietf.org>; Wed,  5 Nov 2014 07:25:12 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id a13so1548478igq.11 for <dbound@ietf.org>; Wed, 05 Nov 2014 07:25:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tzh2LdXvzudPPFY5uTQPONp/qahPb/ItWQ00HOQV25I=; b=FWwSccXc7nxvmk3h6Vqd7cVE8/DKr7wby1TKbgyPJwUrOWBLbqIBKjzTwDKtk+MiWN T29IEHCHvAK1SrV4pYoh55NZ9O+IkOw4itQ/He+D85G4g4S9QL3COtkUYn5UUE9vFlS2 8ANKDcM9NkUmdcJXcl8hbfiYoiEFookBp/EC4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tzh2LdXvzudPPFY5uTQPONp/qahPb/ItWQ00HOQV25I=; b=gnMmuWTxpyfiQiYB9RYGYDLIELq1PZ31/bzjzRrnS+DbyyQKNbInuB22Y635kDRSXu OYmvGhEU/xJyQkAOCCAxjzrFZitMvYbAdO6cz9CwYdo6Mz3oA+aEyXnCN2HxJk8y4f3C qvEbEMG9xMWwydjXR/fcjVa2h/B330YmkEq+CF/wuDgM7+w8vrNrmPRxKUCF+EyyzLhe 40uJ8Ox9/s0phwss50jsDNxz+JIQtEx5J+I/qv6SJHYJkoeDpDrXNF88Mq/TWY0GoBaT 2NcZJ93QHI6VuWJYeYldTehIUjGeja8GtEU++PJOkREDUGYIA0TkfRzYYEl28m9OZvdk j4nw==
X-Gm-Message-State: ALoCoQkxlrwtisfwq5gnXxKKEbOf5Jv2ICkPT6y0+lAXEYQOJ+XAWmWFH0ddsePVAWMpN4kksr0L
MIME-Version: 1.0
X-Received: by 10.42.236.205 with SMTP id kl13mr5060370icb.7.1415201111949; Wed, 05 Nov 2014 07:25:11 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 07:25:11 -0800 (PST)
In-Reply-To: <D07F986D.544A%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org>
Date: Wed, 5 Nov 2014 10:25:11 -0500
Message-ID: <CAEKtLiRsoQryCduBA45rPDKkLOHPU_mJ4pNzw_gFp6fBnZbOSQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary=20cf302920fa90b19405071e2f4a
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/dEEYy4KhrOO-uOzCb3O1a3CzTLM
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 15:25:20 -0000

--20cf302920fa90b19405071e2f4a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 5, 2014 at 9:21 AM, Edward Lewis <edward.lewis@icann.org> wrote=
:

> But on to the discussion of whether upper level domains are exculsive-or
> public or private.  The problem I have is that in making such a divide (o=
r
> any exclusive-or divide) if there are corner cases you=E2=80=99ll pay for=
 it
> later.


Perhaps.  The intent of the problem statement was to lay out a model for
understanding domain relationships, including public/private boundaries.
The boundaries already exist.  That's not new, nor is it a solution: it's
simply the way it is right now.  Whether or not those are (or can be)
accurately captured (that is, including corner cases) with the PSL or
anything else for that matter is yet to be determined/evaluated.  That's
why it is mentioned in the problem statement (first bullet under "problem
statement" Section 4).

"Paying for it" also depends on the application consuming the solution.
There have been some issues over the years with the PSL (you can browse the
bug reports for examples), but there are different consequences for being
"more specific" than "less specific" for example, and even those differ
depending on whether the application is cookies, DMARC, etc.

  I=E2=80=99m not sold that one can cleanly divide the domains, if so,
> whether it is meaningful - and I wretch in my seat because these are
> really zones, not domains.


I can recommend alternative seating.  :)


> E.g., dotUS is a mix of delegations and data.
> Perhaps you can call US public (for the most part it is), but it has some
> private elements.


Hmm, this is exactly why we *are* talking about domains and not zones.  And
the model covers such mixes (as does the PSL--see the entries), completely
independent of zone cuts.


> And E.g., compare how dotUK has been run (until the
> recent policy change) versus CO.UK.  dotUK is essentially private (and
> signed with NSEC to boot) but CO.UK. would be public.
>

If you haven't had a chance to look at the current contents of the PSL, I
invite you to take a look.  It contains examples applying the model
described in the problem statement document.  There are even (gasp!)
comments and references.

I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on why we =
are labeling
> domains as public or private.
>

As I mentioned, much of the problem statement is intended to cover
background, terminology, and current state.  The actual (proposed) "problem
statement" is in Section 4.


> Looking forward to getting to a problem statement.  And I do believe that
> there may be more than one problem to solve, which is why we seem to be
> going (if that can be said) in circles.
>

Yep.  That's part of the reason I've tried to break things down.  Some of
the solutions that have been proposed--pre-problem statement--have had the
feel of solving the entire problem of domain relationships (or boundaries)
with a single blow.  Without having a finer grained understanding of the
problems (which may or may not be compounded) it is difficult to assess the
net effectiveness of those solutions.

Casey

--20cf302920fa90b19405071e2f4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 5, 2014 at 9:21 AM, Edward Lewis <span dir=3D"=
ltr">&lt;<a href=3D"mailto:edward.lewis@icann.org" target=3D"_blank">edward=
.lewis@icann.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But on to the discussio=
n of whether upper level domains are exculsive-or<br>
public or private.=C2=A0 The problem I have is that in making such a divide=
 (or<br>
any exclusive-or divide) if there are corner cases you=E2=80=99ll pay for i=
t<br>
later.</blockquote><div><br></div><div>Perhaps.=C2=A0 The intent of the pro=
blem statement was to lay out a model for understanding domain relationship=
s, including public/private boundaries.=C2=A0 The boundaries already exist.=
=C2=A0 That&#39;s not new, nor is it a solution: it&#39;s simply the way it=
 is right now.=C2=A0 Whether or not those are (or can be) accurately captur=
ed (that is, including corner cases) with the PSL or anything else for that=
 matter is yet to be determined/evaluated.=C2=A0 That&#39;s why it is menti=
oned in the problem statement (first bullet under &quot;problem statement&q=
uot; Section 4).<br><br></div><div>&quot;Paying for it&quot; also depends o=
n the application consuming the solution.=C2=A0 There have been some issues=
 over the years with the PSL (you can browse the bug reports for examples),=
 but there are different consequences for being &quot;more specific&quot; t=
han &quot;less specific&quot; for example, and even those differ depending =
on whether the application is cookies, DMARC, etc.<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">=C2=A0 I=E2=80=99m not sold that one can cleanly divide=
 the domains, if so,<br>
whether it is meaningful - and I wretch in my seat because these are<br>
really zones, not domains.</blockquote><div><br></div><div>I can recommend =
alternative seating.=C2=A0 :)<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">E.g., dotUS is a mix of delegations and data.<br>
Perhaps you can call US public (for the most part it is), but it has some<b=
r>
private elements.</blockquote><div><br></div><div>Hmm, this is exactly why =
we *are* talking about domains and not zones.=C2=A0 And the model covers su=
ch mixes (as does the PSL--see the entries), completely independent of zone=
 cuts.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And E.g., c=
ompare how dotUK has been run (until the<br>
recent policy change) versus <a href=3D"http://CO.UK" target=3D"_blank">CO.=
UK</a>.=C2=A0 dotUK is essentially private (and<br>
signed with NSEC to boot) but <a href=3D"http://CO.UK" target=3D"_blank">CO=
.UK</a>. would be public.=C2=A0<br></blockquote><div><br></div><div>If you =
haven&#39;t had a chance to look at the current contents of the PSL, I invi=
te you to take a look.=C2=A0 It contains examples applying the model descri=
bed in the problem statement document.=C2=A0 There are even (gasp!) comment=
s and references.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on why we =
are labeling<br>
domains as public or private.<br></blockquote><div><br></div><div>As I ment=
ioned, much of the problem statement is intended to cover background, termi=
nology, and current state.=C2=A0 The actual (proposed) &quot;problem statem=
ent&quot; is in Section 4.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Looking forward to getting to a problem statement.=C2=A0 And I do believe t=
hat<br>
there may be more than one problem to solve, which is why we seem to be<br>
going (if that can be said) in circles.<br></blockquote><div><br></div><div=
>Yep.=C2=A0 That&#39;s part of the reason I&#39;ve tried to break things do=
wn.=C2=A0 Some of the solutions that have been proposed--pre-problem statem=
ent--have had the feel of solving the entire problem of domain relationship=
s (or boundaries) with a single blow.=C2=A0 Without having a finer grained =
understanding of the problems (which may or may not be compounded) it is di=
fficult to assess the net effectiveness of those solutions.<br><br></div></=
div><div class=3D"gmail_quote">Casey<br></div></div></div>

--20cf302920fa90b19405071e2f4a--


From nobody Wed Nov  5 07:58:44 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D151A89AC for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 07:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGl9x93jDaMn for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 07:58:40 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847A61A89A3 for <dbound@ietf.org>; Wed,  5 Nov 2014 07:58:40 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id tr6so971647ieb.18 for <dbound@ietf.org>; Wed, 05 Nov 2014 07:58:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s/bQd38qMM7wfujb50QUw7rOSZkF8jRvR/45olev2pg=; b=ZaHsdGQBV1r4BvUHajYwUM9Yl8a9wsnjAERdR8XK9M5poI58b0cc8P7ZFqQOxMmQyh Q3yeCOMsJm/hvpSOODuj4UA+MQkkhwZ4FGNd/MsHjBlvZqqe2SH7f3ZuPHNCBvxrB9s0 rwJxd1+OvJtiedX2jVthHFbfNpazYWg/uDKWo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s/bQd38qMM7wfujb50QUw7rOSZkF8jRvR/45olev2pg=; b=ifDVUbJshJornx0rVKvK8E9NXZc+mRsbvlQWjhaRggsIyk+aqag1Z4Kk+d8wLAvmdD BWG3YB7xY2bc+RwfK8Z8Vhm50/XRzGy8sdKPvCwhwR4L2sHh4uha16Oq6zwwzvQBQ1jn E76moRslx8OxfYDUNPZC8E2lH1Um7vX+MyQGEGZV8NE/n2ZKjmM91ELGQaP2d8FOnCca FZoEAyrTyK1qEFNkPAb9ZdVhXo9uMtFSM7Jg74kKyV72Eqhyocxpc+/NqInaFbIvZAnF bh8SDhN3bpce7/vAzqO2MTSQ0jkCiAAEvd3z8Ev9gRGR14hLGcBj256PX4UheWioMtUQ rlHw==
X-Gm-Message-State: ALoCoQnxoYHLYin1RXT9EzeXWHduYinoR+cmp1NYuhOWzhnwCb8h1MqpQJG75F7HJRIuoAEHUJmO
MIME-Version: 1.0
X-Received: by 10.42.236.205 with SMTP id kl13mr5260690icb.7.1415203119621; Wed, 05 Nov 2014 07:58:39 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 07:58:39 -0800 (PST)
In-Reply-To: <20141105143630.GD30379@mx1.yitter.info>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org> <20141105143630.GD30379@mx1.yitter.info>
Date: Wed, 5 Nov 2014 10:58:39 -0500
Message-ID: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary=20cf302920fa3af94305071ea727
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/F3oviDj2BlV-1WAh-5aGVjmS8fg
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 15:58:42 -0000

--20cf302920fa3af94305071ea727
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andrew,

On Wed, Nov 5, 2014 at 9:36 AM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

> On Wed, Nov 05, 2014 at 02:21:49PM +0000, Edward Lewis wrote:
> >
> > I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on why=
 we are labeling
> > domains as public or private.
>
> Your concern is precisely why, in my previous stabs at this, I have
> attempted to avoid that.  It's the wrong classification, IMO, even if
> it's a useful rule of thumb sometimes; and too much confusion has
> resulted from trying to use it.
>

Since we're laying out the problem statement, any clarification on "too
much confusion has resulted..." is welcome.  I assume you're referring to
the PSL, but do you mean confusion related to the transparency of list
modification, clarity of the algorithm specification, or resulting from
mishaps (e.g., k12.hi.us)? How do you quantify "too much"?  What is the
demand for identifying domain relationships, other than what the PSL
provides (public/private boundaries)?  I don't doubt that there is such
demand (and some of it has already been identified), but that is what needs
to be brought to the forefront as part of the problem statement.


> Instead, we should be looking for a way of grouping identifiers
> according to other classifications.  The motivating stuff in the
> earlier I-Ds I wrote or worked on with Jeff is there to explain why
> the DNS hierarchy is _not_ the right classification, despite the
> attempts in the past to use it.
>

Perhaps--but that is in line with solution consideration, not problem
identification.  I don't think there is a question about whether or not
there so-called public/private boundaries currently exist in the domain
space.  To me, the questions are in understanding the consuming
applications for domain relationships and using their properties (e.g.,
domain ancestry, public/private boundaries) to determine how to most
effectively meet the current and future demand for domain relationships,
all things considered.


> Unfortunately, to my way of thinking, people who have running code
> that is already based on the faulty reading of the hierarchy are
> unlikely to change that enough to work with new arbitrary groupings.
> Moreover, there's the additional problem that allowing arbitrary links
> out of hierarchy will potentially explode the data that clients have
> to pay attention to, and nobody is enthusiastic about that.
>

Those are both considerations (though not constraints, per se) that need to
be made when designing and evaluating solutions.

Cheers,
Casey

--20cf302920fa3af94305071ea727
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andrew,<br><div><br>On Wed, Nov 5, 2014 at 9:36 AM, And=
rew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:ajs@anvilwalrusden.com=
" target=3D"_blank">ajs@anvilwalrusden.com</a>&gt;</span> wrote:<br><div cl=
ass=3D"gmail_extra"><div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<span>On Wed, Nov 05, 2014 at 02:21:49PM +0000, Edward Lewis wrote:<br>
&gt;<br>
&gt; I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on wh=
y we are labeling<br>
&gt; domains as public or private.<br>
<br>
</span>Your concern is precisely why, in my previous stabs at this, I have<=
br>
attempted to avoid that.=C2=A0 It&#39;s the wrong classification, IMO, even=
 if<br>
it&#39;s a useful rule of thumb sometimes; and too much confusion has<br>
resulted from trying to use it.<br></blockquote><div><br></div><div>Since w=
e&#39;re laying out the problem statement, any clarification on &quot;too m=
uch confusion has resulted...&quot; is welcome.=C2=A0 I assume you&#39;re r=
eferring to the PSL, but do you mean confusion related to the transparency =
of list modification, clarity of the algorithm specification, or resulting =
from mishaps (e.g., <a href=3D"http://k12.hi.us">k12.hi.us</a>)? How do you=
 quantify &quot;too much&quot;?=C2=A0 What is the demand for identifying do=
main relationships, other than what the PSL provides (public/private bounda=
ries)?=C2=A0 I don&#39;t doubt that there is such demand (and some of it ha=
s already been identified), but that is what needs to be brought to the for=
efront as part of the problem statement.<br></div><div>=C2=A0</div></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Instead, we should be looking for a way of grouping identifiers<br>
according to other classifications.=C2=A0 The motivating stuff in the<br>
earlier I-Ds I wrote or worked on with Jeff is there to explain why<br>
the DNS hierarchy is _not_ the right classification, despite the<br>
attempts in the past to use it.<br></blockquote><div><br></div><div>Perhaps=
--but that is in line with solution consideration, not problem identificati=
on.=C2=A0 I don&#39;t think there is a question about whether or not there =
so-called public/private boundaries currently exist in the domain space.=C2=
=A0 To me, the questions are in understanding the consuming applications fo=
r domain relationships and using their properties (e.g., domain ancestry, p=
ublic/private boundaries) to determine how to most effectively meet the cur=
rent and future demand for domain relationships, all things considered.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Unfortunately, to my way of thinking, people who have running code<br>
that is already based on the faulty reading of the hierarchy are<br>
unlikely to change that enough to work with new arbitrary groupings.<br>
Moreover, there&#39;s the additional problem that allowing arbitrary links<=
br>
out of hierarchy will potentially explode the data that clients have<br>
to pay attention to, and nobody is enthusiastic about that.<br></blockquote=
><div><br></div><div>Those are both considerations (though not constraints,=
 per se) that need to be made when designing and evaluating solutions.<br><=
br></div><div>Cheers,<br></div><div>Casey<br></div></div></div></div></div>

--20cf302920fa3af94305071ea727--


From nobody Wed Nov  5 08:36:32 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1D1A89E5 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 08:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npcin6KOooFO for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 08:36:30 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B0D1A89EF for <dbound@ietf.org>; Wed,  5 Nov 2014 08:36:30 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 48DC48A035 for <dbound@ietf.org>; Wed,  5 Nov 2014 16:36:29 +0000 (UTC)
Date: Wed, 5 Nov 2014 11:36:27 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141105163627.GL30379@mx1.yitter.info>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org> <20141105143630.GD30379@mx1.yitter.info> <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/BvubXST2ZdE_DlcCltGQcsL-LJY
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 16:36:31 -0000

On Wed, Nov 05, 2014 at 10:58:39AM -0500, Casey Deccio wrote:

> identification.  I don't think there is a question about whether or not
> there so-called public/private boundaries currently exist in the domain
> space.

Actually, this is to me precisely the question.  I have been arguing
that the public/private distinction is actually a miscategorization of
the problem.  It's a good rule of thumb in lots of cases, but the
corners where the distinction breaks down are instructive.

For instance, some universities have delegated name spaces to
departments.  Is this a public registry, or a private one?  Well,
neither, exactly.  In some sense, this is a delegation across
organization boundaries, and the policies in one are most assuredly
not the policies in another.  In some other sense, they're all part of
the same legal entity.  Similarly, I really don't think it is a good
thing if information leaks between different government departments,
yet in some sense everything under gc.ca is in the same organization.
Or anyway, Stephen Harper wishes it were.

These cases show that the public/private distinction is not actually
clean enough.  

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Wed Nov  5 08:51:29 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F42F1A89A9 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 08:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAaP2RkWRFUg for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 08:51:25 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9951F1A89A5 for <dbound@ietf.org>; Wed,  5 Nov 2014 08:51:25 -0800 (PST)
Received: (qmail 72462 invoked from network); 5 Nov 2014 16:51:24 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Nov 2014 16:51:24 -0000
Date: 5 Nov 2014 16:51:02 -0000
Message-ID: <20141105165102.81434.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/XOWJ7qFjduNCVlWXvEHOVyjS_ws
Cc: casey@deccio.net
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 16:51:27 -0000

>Perhaps--but that is in line with solution consideration, not problem
>identification.  I don't think there is a question about whether or not
>there so-called public/private boundaries currently exist ...

There are certainly boundaries, but they're not necessarily
public/private.  For example, uk.com sells subdomains like foo.uk.com.
So the boundary between com and bigbank.com is public/private while
that between com and uk.com is, uh, public/public or maybe something
else.

For me the goal has been to mark groups of names under the same
control (for some suitably vague definition of "same".)  In this
example, com is one group, uk.com is a second, and foo.uk.com and its
subdomains are a third.  I don't see any benefit in labelling a group
as public or private.  This grouping idea also allows us to avoid
for the moment deciding whether we want to group kitty.cat and kĂ­tty.cat.

R's,
John


From nobody Wed Nov  5 09:16:29 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3AB1A8A0F for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bvpf15yhKa9 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:16:26 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE6A1A8A83 for <dbound@ietf.org>; Wed,  5 Nov 2014 09:15:05 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id h3so9136792igd.2 for <dbound@ietf.org>; Wed, 05 Nov 2014 09:15:05 -0800 (PST)
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-type; bh=qa0Wp0YNanv/dGO9l+sB4ibJWD26RuthKuD46ohOF1Y=; b=tSXfA7IsIBoSieptJYpnfKyl1Es/vCnMxSQZXhdOllms/HeObC9pMVYuYBopB4xC/y z91Hsn5X8lj5BO5oa+JDxU+caAOQw4wPUdWj6MRRtvKuTzL/FvHVBpliDHhDhxg84+Os mYwjKh3aSoLLB5MwsuGGZcSWZ7fKTd5ldbhVRj7sKGryi9iJy20W2G/5Ulpmy2sggZh3 Du5Jy1JWB3tQkZBnmW2AFMJWre1n0rRzgeklhhZruGgHI3Wnhx6IdHXmE8tZX86qQzS9 G9vegxfW5deswaeC01odyZWErfko+vFeK5gOQAPonVQt/d4yBTZHrTpsBBZTX3v/FgFq yTVg==
MIME-Version: 1.0
X-Received: by 10.107.130.218 with SMTP id m87mr63509496ioi.8.1415207705062; Wed, 05 Nov 2014 09:15:05 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Wed, 5 Nov 2014 09:15:04 -0800 (PST)
In-Reply-To: <20141105165102.81434.qmail@ary.lan>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan>
Date: Wed, 5 Nov 2014 12:15:04 -0500
Message-ID: <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/k9RJUJo6cQ0YN3nvRmcPEKY-TOQ
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 17:16:27 -0000

On Wed, Nov 5, 2014 at 11:51 AM, John Levine <johnl@taugh.com> wrote:
>>Perhaps--but that is in line with solution consideration, not problem
>>identification.  I don't think there is a question about whether or not
>>there so-called public/private boundaries currently exist ...
>
> There are certainly boundaries, but they're not necessarily
> public/private.  For example, uk.com sells subdomains like foo.uk.com.
> So the boundary between com and bigbank.com is public/private while
> that between com and uk.com is, uh, public/public or maybe something
> else.
>
+1

I'm interested in two boundaries. First, where are the gTLDs and
ccTLDs so I can perform a pre-flight check. Second, where are the
administrative boundaries for a non-TLD that might need to be checked
online.


From nobody Wed Nov  5 09:19:23 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7E1A8A0D for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP72SMtPFwWm for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:19:20 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597D51A8ADD for <dbound@ietf.org>; Wed,  5 Nov 2014 09:19:11 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 394878A035 for <dbound@ietf.org>; Wed,  5 Nov 2014 17:19:10 +0000 (UTC)
Date: Wed, 5 Nov 2014 12:19:08 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141105171908.GU30379@mx1.yitter.info>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/VPSwAoN82SRkdgwTSpU6wQcH3Kk
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 17:19:21 -0000

On Wed, Nov 05, 2014 at 12:15:04PM -0500, Jeffrey Walton wrote:
> I'm interested in two boundaries. First, where are the gTLDs and
> ccTLDs so I can perform a pre-flight check.

I'd be interested to know what knowing those gains you.  (And is it
that you want to know which are g and which cc, or just all the TLDs?)

> Second, where are the
> administrative boundaries for a non-TLD that might need to be checked
> online.

This is the one that I've been arguing for.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Wed Nov  5 09:48:07 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1D1A9037 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9QVlpkwTINt for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:48:03 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7634C1A903A for <dbound@ietf.org>; Wed,  5 Nov 2014 09:48:03 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn18so9172528igb.13 for <dbound@ietf.org>; Wed, 05 Nov 2014 09:48:02 -0800 (PST)
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-type; bh=XX41ZGiBBm1zLFykGWpFhUFIBdvKVkb8h7apn0hq2+A=; b=vXekoMbMcfdsbH4Bf+hC+6qhr6vq9Fz6Tg5+dpfdPcWsQc7m0TUYVeYW0qWFtBHwi3 L149+udP5wmmGIIc/NumWmCC7CJ9WcwsE1XxcptN+OpvEdQWBxLKtm6nY4JH6LeZjzyA WABfLZSV33lLFsGt99QoMngOo9xbZNw1A9pnndtEwHTmw5UPPPI12AjQlpxsG78VEhvf 6IWA5bLpSCsv1VDBAfitd9hwdJq3AsMSYRmwTUXq8QJ++/Aqc/Z+sum/HcL/ruDyorAL oqwxF7YvJXpFKvRT107Iyo+npGd6IIp1Cwb9WJGnBRif6iw++cXliqS0/d/BZb+0V6xf EoSg==
MIME-Version: 1.0
X-Received: by 10.107.28.131 with SMTP id c125mr38320538ioc.29.1415209682707;  Wed, 05 Nov 2014 09:48:02 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Wed, 5 Nov 2014 09:48:02 -0800 (PST)
In-Reply-To: <20141105171908.GU30379@mx1.yitter.info>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com> <20141105171908.GU30379@mx1.yitter.info>
Date: Wed, 5 Nov 2014 12:48:02 -0500
Message-ID: <CAH8yC8m52cAcHNypXHmc--pFgV3atxG7FUr-wZ7aCNto1wLNpw@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/cUPM8cmLnJkGBriteIJvp97tyeY
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 17:48:05 -0000

On Wed, Nov 5, 2014 at 12:19 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> On Wed, Nov 05, 2014 at 12:15:04PM -0500, Jeffrey Walton wrote:
>> I'm interested in two boundaries. First, where are the gTLDs and
>> ccTLDs so I can perform a pre-flight check.
>
> I'd be interested to know what knowing those gains you.  (And is it
> that you want to know which are g and which cc, or just all the TLDs?)

It saves a network call. I'm less worried about the 1RTT, and more
worried about a potential failure that I have to handle. If I don't
need to make the network call, then I don't have to worry about
handling the failure.


From nobody Wed Nov  5 09:59:15 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78E21A906D for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BJfvU053ei1 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 09:59:13 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3131A88EE for <dbound@ietf.org>; Wed,  5 Nov 2014 09:59:13 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1FD6A8A035 for <dbound@ietf.org>; Wed,  5 Nov 2014 17:59:12 +0000 (UTC)
Date: Wed, 5 Nov 2014 12:59:10 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141105175910.GW30379@mx1.yitter.info>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com> <20141105171908.GU30379@mx1.yitter.info> <CAH8yC8m52cAcHNypXHmc--pFgV3atxG7FUr-wZ7aCNto1wLNpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH8yC8m52cAcHNypXHmc--pFgV3atxG7FUr-wZ7aCNto1wLNpw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/CgeMQ_M5dgE6B38hnVViykajTWU
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 17:59:14 -0000

On Wed, Nov 05, 2014 at 12:48:02PM -0500, Jeffrey Walton wrote:
> It saves a network call. I'm less worried about the 1RTT, and more
> worried about a potential failure that I have to handle. If I don't
> need to make the network call, then I don't have to worry about
> handling the failure.

Wouldn't it be better, in that case, to have a general cache about
boundaries, with information about how stale it is likely to be?  That
is, it's not TLDs you want, but attestations from zones that they let
anyone register within them, right?  For these purposes, there's no
difference between "com" and "dyndns.org", I think.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Wed Nov  5 10:02:49 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1742D1A907A for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52LsJMWY1IrU for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:02:40 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8531A9040 for <dbound@ietf.org>; Wed,  5 Nov 2014 10:02:40 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 10:02:38 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 10:02:38 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "noloader@gmail.com" <noloader@gmail.com>, Andrew Sullivan <ajs@anvilwalrusden.com>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAV+8AgAAW9ICAAA6jAIAABrcAgAABIwCAAAgTAP//sDsA
Date: Wed, 5 Nov 2014 18:02:38 +0000
Message-ID: <D07FCF00.547C%edward.lewis@icann.org>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com> <20141105171908.GU30379@mx1.yitter.info> <CAH8yC8m52cAcHNypXHmc--pFgV3atxG7FUr-wZ7aCNto1wLNpw@mail.gmail.com>
In-Reply-To: <CAH8yC8m52cAcHNypXHmc--pFgV3atxG7FUr-wZ7aCNto1wLNpw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [68.98.142.232]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498037352_4839106"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/2Rp7JaDfdUl4txHtG5TVpSmHMSo
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 18:02:45 -0000

--B_3498037352_4839106
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

-----Original Message-----
From: Jeffrey Walton <noloader@gmail.com>
Reply-To: "noloader@gmail.com" <noloader@gmail.com>
Date: Wednesday, November 5, 2014 at 12:48
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>On Wed, Nov 5, 2014 at 12:19 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
>wrote:
>> On Wed, Nov 05, 2014 at 12:15:04PM -0500, Jeffrey Walton wrote:
>>> I'm interested in two boundaries. First, where are the gTLDs and
>>> ccTLDs so I can perform a pre-flight check.
>>
>> I'd be interested to know what knowing those gains you.  (And is it
>> that you want to know which are g and which cc, or just all the TLDs?)
>
>It saves a network call. I'm less worried about the 1RTT, and more
>worried about a potential failure that I have to handle. If I don't
>need to make the network call, then I don't have to worry about
>handling the failure.

Like Andrew, I had the same question.  Your answer still leaves me
wondering.

I don=E2=80=99t mean to lead the witness, but what do you mean by a 'network
call=E2=80=99?  If this relates to what happens in something planning to iterate
through the DNS, could you describe further?  A caching element wouldn=E2=80=99t
care so much because it=E2=80=99ll look to find, if not the answer, the nearest
cut point it has and launch from there, regardless whether it is a TLD or
not.  If this is an application doing DNS queries without fully
implementing DNS (caching), well, that=E2=80=99d be interesting to know.

I=E2=80=99m taking 'network call' as a system call that causes a IP traffic to
flow, perhaps via a stub resolver (which by definition doesn=E2=80=99t iterate),
or perhaps via something else...

--B_3498037352_4839106
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBS2Nlu/BD1Yxhf6/OuU
rFousNbOyzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDUxODAyMzJaMA0GCSqGSIb3DQEBAQUABIIBAL4mw9qLJt1PB8fJ7mNefoZ5KOKvYpyG1PBt
iFL6Cb+2EXIBdPpYENpCJeRpd6HIkRr91oDkiulOafNEzBOdZtU8ieNYID0j3zdVgTQHeA+w
hA5EeSElDs3itI/6nLOXypep43HZSECYzKg5XXiGhqLAD72yLRTl0tWPMaFkBHepvjpORSTV
OXizP65lixoHpH4Rp5MDJ4hCTqkStVrYPkj3VtUTWlcj3FCbzzly/mCmh3KaHwGB8uOAjLDv
jHMRIgHGU8GSpa59n9wUjUWPYBxvt9gTnq69BISNR/4W1axg9k/CYqxnyojiuO6WoaGkQtqo
a5v2WOvmxe5GsmlzJk8=

--B_3498037352_4839106--


From nobody Wed Nov  5 10:29:38 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C92D1A9104 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN-emc0aZc7P for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:29:35 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329971A910E for <dbound@ietf.org>; Wed,  5 Nov 2014 10:29:32 -0800 (PST)
Received: by mail-ig0-f173.google.com with SMTP id r10so9277605igi.0 for <dbound@ietf.org>; Wed, 05 Nov 2014 10:29:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pl2Ub6EtXsOV2k/xaZFlKK/RRh25OhXYlhLk49n0wK4=; b=DbzLcNiF/TvSPMmjTfAYmQG48Yu8iMtW38dH688FZkWIhm8G/UO1S0RvhOBiuJN5sQ N+owpIEau2+gi21wb29o6oaWIF4jvh3b9rdjLHQ9FEs2uw05TrqvxBYVnQ/axXz21IBS nlY9VA4eZgsgts3oEk4ykgE617wYUibflAXFA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pl2Ub6EtXsOV2k/xaZFlKK/RRh25OhXYlhLk49n0wK4=; b=gNpSc1+s70+lo8sfB/4vYAcMuigu6liqrRN0mPRBBhQnUAtqWbIqY3R72rx5XpWTkg Kfnnv6o/j7f0IZU9ycTOYaILaj3w8IRWpQayDxBgT5O4DZG6TFDw2BWPBOV51c+p+U+8 ksAf8yN6BWCwoqeKYzeZQzfFdErTFqxmEVxXG958CFh4W+NjqX/SOl/V2BT5hnGKR5Gi /+2h2KYsp1VrtWykGYo2AK6edLn+EsOpT4PHcMnCX/J51e4nrLNFZa1ocwhyKzSxX0px vJENMnMg+pVqTFTeMIW6eURJ+PFKndbEVzNT/EjAHLuBs4FkTNx/jzKXpHq5/cdj5XOb Vgyw==
X-Gm-Message-State: ALoCoQm/5AFdOUPKCLtUR+eLgFwwPtRzstUCcW40GGWoBiICSKWmHjePhEiAlpVAVrf2sE7wHuJS
MIME-Version: 1.0
X-Received: by 10.107.11.129 with SMTP id 1mr64179845iol.18.1415212171339; Wed, 05 Nov 2014 10:29:31 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 10:29:31 -0800 (PST)
In-Reply-To: <20141105163627.GL30379@mx1.yitter.info>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org> <20141105143630.GD30379@mx1.yitter.info> <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105163627.GL30379@mx1.yitter.info>
Date: Wed, 5 Nov 2014 13:29:31 -0500
Message-ID: <CAEKtLiTXP5yfbX4=Lk5oj7JejHBCa_4y_8ZA9gvxT6QUNvyYdw@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary=001a113de586c16bea050720c22a
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Ks2AYBjkp22g9YELjj5LRQvc1Qc
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 18:29:37 -0000

--001a113de586c16bea050720c22a
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 5, 2014 at 11:36 AM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

> On Wed, Nov 05, 2014 at 10:58:39AM -0500, Casey Deccio wrote:
>
> > identification.  I don't think there is a question about whether or not
> > there so-called public/private boundaries currently exist in the domain
> > space.
>
> Actually, this is to me precisely the question.  I have been arguing
> that the public/private distinction is actually a miscategorization of
> the problem.  It's a good rule of thumb in lots of cases, but the
> corners where the distinction breaks down are instructive.
>

My feeling is that the problems with miscategorization are often because
this categorization is the *only* one that has been used predominantly
(outside of simple ancestral relationships), not because there aren't such
things as public/private boundaries.

Or... The misuse of a hammer does not mean that we need to reevaluate
whether striking it on nails is appropriate.  Rather, it means that we need
to reevaluate the uses of the hammer and the goals that we are trying to
accomplish with it.


>
> For instance, some universities have delegated name spaces to
> departments.  Is this a public registry, or a private one?  Well,
> neither, exactly.  In some sense, this is a delegation across
> organization boundaries, and the policies in one are most assuredly
> not the policies in another.  In some other sense, they're all part of
> the same legal entity.  Similarly, I really don't think it is a good
> thing if information leaks between different government departments,
> yet in some sense everything under gc.ca is in the same organization.
> Or anyway, Stephen Harper wishes it were.
>
> These cases show that the public/private distinction is not actually
> clean enough.
>

The draft problem statement document distributed to the list describes
public/private boundaries as only one property of domains.  It also
considers (for example) intra-scope relationships, and provides an example
nearly identical to the one you provided above (see section 1.1.4).

I am not arguing that public/private boundaries are *the* way to solve
things, nor am I suggesting that the definition of "public" is sufficiently
clear, as currently defined.  But to me there there is an apparent
distinction between a delegation from, say, "org" to "foo.org" and a
delegation from "foo.edu" to "cs.foo.edu".  In the proposal that would be
the difference between "public -> private" and "private -> private".
Inferring more than that is currently undefined and is referred to in the
third bullet of the problem statement (section 4).

Cheers,
Casey

--001a113de586c16bea050720c22a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 5, 2014 at 11:36 AM, Andrew Sullivan <span dir=
=3D"ltr">&lt;<a href=3D"mailto:ajs@anvilwalrusden.com" target=3D"_blank">aj=
s@anvilwalrusden.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On=
 Wed, Nov 05, 2014 at 10:58:39AM -0500, Casey Deccio wrote:<br>
<br>
&gt; identification.=C2=A0 I don&#39;t think there is a question about whet=
her or not<br>
&gt; there so-called public/private boundaries currently exist in the domai=
n<br>
&gt; space.<br>
<br>
</span>Actually, this is to me precisely the question.=C2=A0 I have been ar=
guing<br>
that the public/private distinction is actually a miscategorization of<br>
the problem.=C2=A0 It&#39;s a good rule of thumb in lots of cases, but the<=
br>
corners where the distinction breaks down are instructive.<br></blockquote>=
<div><br></div><div>My feeling is that the problems with miscategorization =
are often because this categorization is the *only* one that has been used =
predominantly (outside of simple ancestral relationships), not because ther=
e aren&#39;t such things as public/private boundaries.<br><br>Or... The mis=
use of a hammer does not mean that we need to reevaluate whether striking i=
t on nails is appropriate.=C2=A0 Rather, it means that we need to reevaluat=
e the uses of the hammer and the goals that we are trying to accomplish wit=
h it.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For instance, some universities have delegated name spaces to<br>
departments.=C2=A0 Is this a public registry, or a private one?=C2=A0 Well,=
<br>
neither, exactly.=C2=A0 In some sense, this is a delegation across<br>
organization boundaries, and the policies in one are most assuredly<br>
not the policies in another.=C2=A0 In some other sense, they&#39;re all par=
t of<br>
the same legal entity.=C2=A0 Similarly, I really don&#39;t think it is a go=
od<br>
thing if information leaks between different government departments,<br>
yet in some sense everything under <a href=3D"http://gc.ca" target=3D"_blan=
k">gc.ca</a> is in the same organization.<br>
Or anyway, Stephen Harper wishes it were.<br>
<br>
These cases show that the public/private distinction is not actually<br>
clean enough.<br></blockquote><div><br></div><div>The draft problem stateme=
nt document distributed to the list describes public/private boundaries as =
only one property of domains.=C2=A0 It also considers (for example) intra-s=
cope relationships, and provides an example nearly identical to the one you=
 provided above (see section 1.1.4).<br><br>I am not arguing that public/pr=
ivate boundaries are *the* way to solve things, nor am I suggesting that th=
e definition of &quot;public&quot; is sufficiently clear, as currently defi=
ned.=C2=A0 But to me there there is an apparent distinction between a deleg=
ation from, say, &quot;org&quot; to &quot;<a href=3D"http://foo.org">foo.or=
g</a>&quot; and a delegation from &quot;<a href=3D"http://foo.edu">foo.edu<=
/a>&quot; to &quot;<a href=3D"http://cs.foo.edu">cs.foo.edu</a>&quot;.=C2=
=A0 In the proposal that would be the difference between &quot;public -&gt;=
 private&quot; and &quot;private -&gt; private&quot;.=C2=A0 Inferring more =
than that is currently undefined and is referred to in the third bullet of =
the problem statement (section 4).<br><br></div><div class=3D"h5">Cheers,<b=
r>Casey<br></div></div></div></div>

--001a113de586c16bea050720c22a--


From nobody Wed Nov  5 10:49:26 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE491A912F for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRxia3vlIUce for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 10:49:21 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11221A1B1C for <dbound@ietf.org>; Wed,  5 Nov 2014 10:49:20 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id a13so1936740igq.11 for <dbound@ietf.org>; Wed, 05 Nov 2014 10:49:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EstU1+Lg18Im0V+rIyCcGqpOpdD/putZAFx/C7y8JFc=; b=fc6z82DZODuMQHBMpTWcf+/5qq8vf8TKydIx5KMatm2zba9VdxfJt80QdFz4KG7sAb h9B6Jm+FJuq7HMrBI799jTnhPpfNAJcMRjwQDaY5BBfBH2DFqVxQgRp/Mq65fJvm2bBg hw2iLqHM5/z03/ubGTyELDObvUJ9HXR364q50=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EstU1+Lg18Im0V+rIyCcGqpOpdD/putZAFx/C7y8JFc=; b=mcv8JyhOYDlFHz4gB6a94WUDeUV5F0LAFf33KqRxa+3mpkl9JRxwWWkctM5MUjSPsb AerqmnylUoxiRQKg68l+sQZbmLZxeKQYbwck5MrTIoL4uc8Z+u8k2AzguRagvgn3iHJi nakF96XhMQsMBfSGFQ7yOZ7pwjAN4w10CE23gAQINsZLwYKUthTVme4kWG21Y5BY/AbA 6tSELebdssRVdxtxCLyVUOFcW3CBxKHvR0xRXNBt44ZqaOjGvZY3ztnNTcD7qrnl5VS7 qC+9km+PmnTe6m4KotSCZODuPqnRUIXKPZGdN6WB0x83+ac8z2F6qBGWF64MgBWa70R2 aX6A==
X-Gm-Message-State: ALoCoQlDYC1T/W9LAIg7L+7PljApdtI9BAMsrqBYvk39dDayVo0JepCujvAzNwW7Oq5KAfwbJd+o
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr5013698ioo.73.1415213360054; Wed, 05 Nov 2014 10:49:20 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 10:49:19 -0800 (PST)
In-Reply-To: <20141105165102.81434.qmail@ary.lan>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan>
Date: Wed, 5 Nov 2014 13:49:19 -0500
Message-ID: <CAEKtLiQxTkHHBazf-s7xJJ0aA51VH_NTJ2Cn07SCDKzs1TBLOA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a113703b49ba0030507210931
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/DbdmXpPPOSZAbD6VoZ8oNkJ7RyI
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 18:49:23 -0000

--001a113703b49ba0030507210931
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 5, 2014 at 11:51 AM, John Levine <johnl@taugh.com> wrote:

> >Perhaps--but that is in line with solution consideration, not problem
> >identification.  I don't think there is a question about whether or not
> >there so-called public/private boundaries currently exist ...
>
> There are certainly boundaries, but they're not necessarily
> public/private.


I believe the current PSL (regardless of limitations) is a testament that
public/private boundaries exist, at least in some fashion.

For example, uk.com sells subdomains like foo.uk.com.
> So the boundary between com and bigbank.com is public/private while
> that between com and uk.com is, uh, public/public or maybe something
> else.
>
>
Two names "uk.com" and "com" (as described in the proposed problem
statement document) would be considered intra-scope, i.e., two public
names, with no boundary.


> For me the goal has been to mark groups of names under the same
> control (for some suitably vague definition of "same".)  In this
> example, com is one group, uk.com is a second, and foo.uk.com and its
> subdomains are a third.  I don't see any benefit in labelling a group
> as public or private.


The benefit, as I see it, is the following.  If we can identify the use
cases for domain relationships, and we find that 99% of the use cases--or,
perhaps more importantly, 99% of demand--falls under category A, with the
balance falling under category B, does it make sense to find a more complex
solution that covers both A and B, or to find two relatively simple
solutions that address A and B, respectively, or something else (for
example)?

In this case, the A and B I'm talking about are public/private boundaries
and arbitrary groupings or relationships.  Presenting the current survey of
the land in terms of domain boundaries, registration, and dynamics, is a
first step to identify the problem space.

Cheers,
Casey

--001a113703b49ba0030507210931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 5, 2014 at 11:51 AM, John Levine <span dir=3D"=
ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.c=
om</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>&gt;Perhaps-=
-but that is in line with solution consideration, not problem<br>
&gt;identification.=C2=A0 I don&#39;t think there is a question about wheth=
er or not<br>
</span>&gt;there so-called public/private boundaries currently exist ...<br=
>
<br>
There are certainly boundaries, but they&#39;re not necessarily<br>
public/private.</blockquote><div><br>I believe the current PSL (regardless =
of limitations) is a testament that public/private boundaries exist, at lea=
st in some fashion.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">For example, <a href=3D"http://uk.com" target=3D"_blank">uk.com</a>=
 sells subdomains like <a href=3D"http://foo.uk.com" target=3D"_blank">foo.=
uk.com</a>.<br>
So the boundary between com and <a href=3D"http://bigbank.com" target=3D"_b=
lank">bigbank.com</a> is public/private while<br>
that between com and <a href=3D"http://uk.com" target=3D"_blank">uk.com</a>=
 is, uh, public/public or maybe something<br>
else.<br>
<br></blockquote><div><br></div><div>Two names &quot;<a href=3D"http://uk.c=
om">uk.com</a>&quot; and &quot;com&quot; (as described in the proposed prob=
lem statement document) would be considered intra-scope, i.e., two public n=
ames, with no boundary.<br></div><div>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
For me the goal has been to mark groups of names under the same<br>
control (for some suitably vague definition of &quot;same&quot;.)=C2=A0 In =
this<br>
example, com is one group, <a href=3D"http://uk.com" target=3D"_blank">uk.c=
om</a> is a second, and <a href=3D"http://foo.uk.com" target=3D"_blank">foo=
.uk.com</a> and its<br>
subdomains are a third.=C2=A0 I don&#39;t see any benefit in labelling a gr=
oup<br>
as public or private.</blockquote><div><br></div><div>The benefit, as I see=
 it, is the following.=C2=A0 If we can identify the use cases for domain re=
lationships, and we find that 99% of the use cases--or, perhaps more import=
antly, 99% of demand--falls under category A, with the balance falling unde=
r category B, does it make sense to find a more complex solution that cover=
s both A and B, or to find two relatively simple solutions that address A a=
nd B, respectively, or something else (for example)?<br><br></div><div>In t=
his case, the A and B I&#39;m talking about are public/private boundaries a=
nd arbitrary groupings or relationships.=C2=A0 Presenting the current surve=
y of the land in terms of domain boundaries, registration, and dynamics, is=
 a first step to identify the problem space.<br></div><div><br>Cheers,<br>C=
asey<br></div></div></div></div>

--001a113703b49ba0030507210931--


From nobody Wed Nov  5 11:16:46 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406491A1BE4 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 11:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54uzxFsz4uQ8 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 11:16:44 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BDD1AC3AA for <dbound@ietf.org>; Wed,  5 Nov 2014 11:16:43 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id a13so9324072igq.11 for <dbound@ietf.org>; Wed, 05 Nov 2014 11:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EzpU1b3eeTZH3lMngCCwlO1IHla1BbhFMOAePFfZfs4=; b=asHxz/WcsXU/PJ1bQuGcN9NRDv6gYwtpHQOoYknwc6P2tP4eo21XfnBuYsBqtpfSEI /8nuZTchwTAtNkMt6F1TCpRpdL9uWtJEjamdHa7e5sJ4YMbFlTeVlWl2uEHyVkzS0Jon +VIpmStsP4Bp1AyOFco16HwoSx0lMMfAtS//Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EzpU1b3eeTZH3lMngCCwlO1IHla1BbhFMOAePFfZfs4=; b=in9nM7pKw7S4EtdiwrgVdGmD/zF8fj0zq+zweMjGomFuCP6ZRZFgS79P0sODrVXkVl +YNlipCXsYcuSGRXxu9iUATlle8Uu/NTgKileQomcfh11q+WNRt0c3DJAAaN2/cF5bOE k/umjyDbiBw1lLFi49RbHUK5yQdRZvi6o6FDUfoZGaFIuUerVmTxMvpuG9BrkoyelkmJ hSI+xJp1XED8NL9D7jN0JDL+VU1wozrExRX30jUzNR6C+l2Vm/m9UQFO3Q8/KDle0sPU gPCZ4vVePE/rmzTvewAU1wb/sJoyxXIQCGz8GxQb1JpmVcQ/a/OJbzslcnNAwGl8ApnC 7tXg==
X-Gm-Message-State: ALoCoQnimYgMlhot8r1nmHYl8O+eilVz96gZDQujb36EpesK0aLAMNkfpM3l3GV3nAJmVqxDChbw
MIME-Version: 1.0
X-Received: by 10.50.43.135 with SMTP id w7mr5509486igl.0.1415215002995; Wed, 05 Nov 2014 11:16:42 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Wed, 5 Nov 2014 11:16:42 -0800 (PST)
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
Date: Wed, 5 Nov 2014 14:16:42 -0500
Message-ID: <CAEKtLiQLVMLRghR6nu_a2krEOfmoOUZKJWNHeK3h=EPzaaKKRw@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=089e01228114890aaf0507216bfd
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/l79bg_ffCdGocKDfPY6fRaWPmcM
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 19:16:45 -0000

--089e01228114890aaf0507216bfd
Content-Type: text/plain; charset=UTF-8

All,

I appreciate the on-list discussion with regard to the content from the
draft problem statement.  I just wanted to draw attention to the obscure
bulleted list in the last section, intended to be the take-away after all
the background concepts are described.

   - Evaluate the effectiveness of the current PSL at performing the
   functions within its scope.
   - Evaluate the effectiveness of the maintenance and distribution of the
   PSL.
   - Determine demand for domain relationship identification other than
   that provided by the PSL.
   - Identify solutions to replace, extend, improve, or complement the
   functionality, maintenance, or distribution of the PSL according to
   perceived demands.

 I just want to make sure that this content is not overlooked as other
relevant topics are discussed.

Also, I am hearing no conflicts with the Tuesday morning time for the "bar"
BoF.  I have a room in mind that will seat about 20 people, and I would
like to know who plans to attend to make sure the venue will work.  Feel
free to RSVP off-list.

If any would like to attend remotely, I can look into something to enable
that, but I it would be best effort :)

Cheers,
Casey

On Tue, Nov 4, 2014 at 10:42 AM, Casey Deccio <casey@deccio.net> wrote:

> Please find attached a draft DBOUND problem statement, resulting from the
> action items taken at the bar BoF in Toronto on the same subject.  Please
> take a read and comment on the document.  There is probably a better format
> for this, but it's a start for now...
>
> Also, if there's interest in a follow-up "bar BoF" (i.e., "unofficial"
> meeting on the subject) in Honolulu, I'm happy to help organize one.  I am
> proposing such a meeting during the Thurs morning session, with alternate
> times being Wed afternoon II and Thurs afternoon III.  If there are enough
> BoF-interested parties that can't make Thurs morning, we can have a doodle
> poll to solidify a time.
>
> In summary:
> - Please read the draft problem statement (attached)
> - Is there some interest in a DBOUND bar BoF?
> - Are there Thurs morning conflicts with a DBOUND bar BoF?
>
> Thanks,
> Casey
>

--089e01228114890aaf0507216bfd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>All,<br><br></div>I appreciate the on-list discu=
ssion with regard to the content from the draft problem statement.=C2=A0 I =
just wanted to draw attention to the obscure bulleted list in the last sect=
ion, intended to be the take-away after all the background concepts are des=
cribed.<br>

=09
	=09
	=09
=09
=09
		<div class=3D"" title=3D"Page 6">
			<div class=3D"">
				<div class=3D""><ul><li>
					Evaluate the effectiveness of the current PSL at performing the functi=
ons within its scope.</li><li>Evaluate the effectiveness of the maintenance=
 and distribution of the PSL.</li><li>Determine demand for domain relations=
hip identification other than that provided by the PSL.</li><li>Identify so=
lutions to replace, extend, improve, or complement the functionality, maint=
enance, or distribution of the PSL according to perceived demands.</li></ul=
></div>
			</div>
		</div>
=09
I just want to make sure that this content is not overlooked as other relev=
ant topics are discussed.<br><br>Also, I am hearing no conflicts with the T=
uesday morning time for the &quot;bar&quot; BoF.=C2=A0 I have a room in min=
d that will seat about 20 people, and I would like to know who plans to att=
end to make sure the venue will work.=C2=A0 Feel free to RSVP off-list.<br>=
<br></div><div>If any would like to attend remotely, I can look into someth=
ing to enable that, but I it would be best effort :)<br></div><div><div><di=
v><br>Cheers,<br>Casey<br><div><div><br>On Tue, Nov 4, 2014 at 10:42 AM, Ca=
sey Deccio <span dir=3D"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=
=3D"_blank">casey@deccio.net</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div><div>Please find attached a draft DBOUND prob=
lem statement, resulting from the action items taken at the bar BoF in Toro=
nto on the same subject.=C2=A0 Please take a read and comment on the docume=
nt.=C2=A0 There is probably a better format for this, but it&#39;s a start =
for now...<br><br></div>Also, if there&#39;s interest in a follow-up &quot;=
bar BoF&quot; (i.e., &quot;unofficial&quot; meeting on the subject) in Hono=
lulu, I&#39;m happy to help organize one.=C2=A0 I am proposing such a meeti=
ng during the Thurs morning session, with alternate times being Wed afterno=
on II and Thurs afternoon III.=C2=A0 If there are enough BoF-interested par=
ties that can&#39;t make Thurs morning, we can have a doodle poll to solidi=
fy a time.<br><br></div><div>In summary:<br></div><div>- Please read the dr=
aft problem statement (attached)<br></div><div>- Is there some interest in =
a DBOUND bar BoF?<br></div><div>- Are there Thurs morning conflicts with a =
DBOUND bar BoF?<br></div><div><div><div><div><div><br>Thanks,<br>Casey<br><=
/div></div></div></div></div></div>
</blockquote></div><br></div></div></div></div></div></div></div>

--089e01228114890aaf0507216bfd--


From nobody Wed Nov  5 11:34:21 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA50E1A6F57 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 11:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr9toN-55mgN for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 11:34:14 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1B71A1B71 for <dbound@ietf.org>; Wed,  5 Nov 2014 11:34:14 -0800 (PST)
Received: (qmail 94270 invoked from network); 5 Nov 2014 19:34:13 -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=1703d.545a7bb5.k1411; bh=Z494oVLYAPCN6MdlXfDwtMQWo9UsUlvEV6YWGlGEHTA=; b=WtihhNWvU6uw3N1Rc5jZ/4rDzDUUdoMBRCZtjCouCPKzvHDQTRdCLb4ORCGPkd/tU4+30RNYHiwvIOkbRVpOtfxSsyhEv8CnqWci7ifbojBneuZD4vMy9aTiePpP72oP70lJc6vO70Jw5zVeqdVWVgkvI2OR92DbzEobtjcIJOhGXvvmnPf0phMyssRAxvike976K2JSVDdzOR6z9M+5UwhMIS3mWfuUrcTNGLR4QCkLOqIKZaOhVsrI+aXrU0QX
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=1703d.545a7bb5.k1411; bh=Z494oVLYAPCN6MdlXfDwtMQWo9UsUlvEV6YWGlGEHTA=; b=LCpf98pGu+cgz9gYW89Nj+qubJX5UTpy3cOcLmju9v8mF12YW/nQoTBacg/w7T/z40MuZaauJwoWjukNRr5LJYYPpvKG3jB7EFMl1mqXyuHuwipy6AoiuBzSyxR5BhLDI8bCyHK8Cn0So4LvGPYm11Kk2bsUl3lR1vVYATzYYORPRRQzwmRgAJcbt0mVqq/wwpaRSJIzW8L6Jc0VzFsaZr3Z5K8ah85stm71hkDxdGvpDEeISd9XyV0K9Z+/Hx//
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; 05 Nov 2014 19:34:13 -0000
Date: 5 Nov 2014 14:34:12 -0500
Message-ID: <alpine.OSX.2.11.1411051431270.26062@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Casey Deccio" <casey@deccio.net>
In-Reply-To: <CAEKtLiQxTkHHBazf-s7xJJ0aA51VH_NTJ2Cn07SCDKzs1TBLOA@mail.gmail.com>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAEKtLiQxTkHHBazf-s7xJJ0aA51VH_NTJ2Cn07SCDKzs1TBLOA@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/775ZozgP3Jzzs5yqWzQ1NDR9OBU
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 19:34:16 -0000

> Two names "uk.com" and "com" (as described in the proposed problem
> statement document) would be considered intra-scope, i.e., two public
> names, with no boundary.

See, that's the problem.  They are in fact different groups.  Verisign 
(who runs the com TLD) would be very unhappy if someone issued a *.com 
certificate to Centralnic (which registered uk.com.)

> The benefit, as I see it, is the following.  If we can identify the use
> cases for domain relationships, and we find that 99% of the use cases--or,
> perhaps more importantly, 99% of demand--falls under category A, with the
> balance falling under category B, does it make sense to find a more complex
> solution that covers both A and B, or to find two relatively simple
> solutions that address A and B, respectively, or something else (for
> example)?

If the 1% where A doesn't work involves catastrophic failures, like 
issuing a *.com certificate, then I think A is in practice a non-starter.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Wed Nov  5 12:21:14 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9D1A6F61 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 12:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUhBiuo7wI9G for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 12:21:10 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2B61A7001 for <dbound@ietf.org>; Wed,  5 Nov 2014 12:17:54 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 12:17:53 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 12:17:52 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAY3iA
Date: Wed, 5 Nov 2014 20:17:52 +0000
Message-ID: <D07FEF92.5494%edward.lewis@icann.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <D07E8E77.5405%edward.lewis@icann.org> <CAEKtLiSJ2admBwMcoQum4LHjTQr252S9+XrJbhOkGLNkS-Q4wg@mail.gmail.com> <D07F986D.544A%edward.lewis@icann.org>
In-Reply-To: <D07F986D.544A%edward.lewis@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [68.98.142.232]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498045467_5343586"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/8hazpAulC4noCdTh63pPwdQtoIw
Cc: Casey Deccio <casey@deccio.net>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 20:21:13 -0000

--B_3498045467_5343586
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Update - I did some fact checking and found that I am wrong about this:

"And E.g., compare how dotUK has been run (until the
recent policy change) versus CO.UK.  dotUK is essentially private (and
signed with NSEC to boot) but CO.UK. would be public.=E2=80=9D

UK isn=E2=80=99t =E2=80=98NSEC' signed and I couldn=E2=80=99t find that it ever was.  I thoug=
ht it
was, but I am wrong.

-----Original Message-----
From: Edward Lewis <edward.lewis@icann.org>
Date: Wednesday, November 5, 2014 at 9:21
To: "dbound@ietf.org" <dbound@ietf.org>
Cc: Casey Deccio <casey@deccio.net>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>Instead of being specific, I=E2=80=99ll offer a general set of comments.  I thin=
k
>Casey and John have captured the state of the group, no argument with
>that, so my observations are about where we are and not the specifics in
>the paper.
>
>Perhaps a mistake we are making is talking (so much) about the DNS
>perspective.  Coming from the remark that zone cuts were avoided because
>we are ruling out zone cut identification as a goal: first, I agree this
>isn=E2=80=99t about zone cut identification.  But once we start analyzing the DN=
S
>side of this, we need to be accurate and faithful to the DNS architecture
>or we will screw this up - as in how one application screwed up an
>understanding of how DNS wild cards work resulting in a mismatch in what
>=E2=80=98match=E2=80=99 means.  (I should cite the specific instance, it has been
>mentioned on the list, but I just can=E2=80=99t find it now.)  That said, I=E2=80=99d
>rather see the group =E2=80=9Cignore=E2=80=9D the DNS for the moment and concentrate o=
n
>what =E2=80=9Cservice=E2=80=9D needs to be defined.
>
>I=E2=80=99m willing to go as far as recognizing that there are identifiers in pl=
ay
>represented as domain names.  Beyond that, such as the fact that they are
>hierarchical and rendered in a format that makes them look more like a
>route than a name, isn=E2=80=99t that important.  In fact I think the paper spen=
ds
>a lot of words describing this and then saying this isn=E2=80=99t what is
>important.  IMHO, it comes to taking two identifiers (represented as
>domain names) and deciding if, for some operation they are to be
>considered the same/treated equally, or (I=E2=80=99ll say it again) equivalent.
>
>The material related to PSL falls into the same boat.  The PSL is a first
>stab at solving some part of the still somewhat hazy problem.  It is the
>crutch used to handle the first use case - the so-called cookies problem,
>better known (again, in my opinion) as the common origin problem.  The PSL
>and the DNS here are more =E2=80=9Clay of the land=E2=80=9D than part of the problem
>statement.  These are two things we have to work with, like unfinished and
>unset modeling clay.
>
>Because of that, take my comments before with a grain of salt.  Perhaps we
>need to go up a level and not down a level (as I was drilling into).
>
>But on to the discussion of whether upper level domains are exculsive-or
>public or private.  The problem I have is that in making such a divide (or
>any exclusive-or divide) if there are corner cases you=E2=80=99ll pay for it
>later.  I=E2=80=99m not sold that one can cleanly divide the domains, if so,
>whether it is meaningful - and I wretch in my seat because these are
>really zones, not domains.  E.g., dotUS is a mix of delegations and data.
>Perhaps you can call US public (for the most part it is), but it has some
>private elements.  And E.g., compare how dotUK has been run (until the
>recent policy change) versus CO.UK.  dotUK is essentially private (and
>signed with NSEC to boot) but CO.UK. would be public.
>
>I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on why we are labelin=
g
>domains as public or private.
>
>Looking forward to getting to a problem statement.  And I do believe that
>there may be more than one problem to solve, which is why we seem to be
>going (if that can be said) in circles.
>
>-----Original Message-----
>From: Casey Deccio <casey@deccio.net>
>Date: Tuesday, November 4, 2014 at 16:18
>To: Edward Lewis <edward.lewis@icann.org>
>Cc: "dbound@ietf.org" <dbound@ietf.org>
>Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
>
>>Hi Ed,
>>
>>On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis
>><edward.lewis@icann.org> wrote:
>>
>>Thanks for writing this up. Now for the complaints. ;)
>>
>>
>>
>>
>>:)
>>=20
>>
>>
>>You lost me at the first sentence of 1.1.1.  (Saying that more
>>dramatically than I mean to.)
>>
>>I don=E2=80=99t have a complete response to the paper.  In the spirit that
>>provoking thoughts is better than not at this point, here are some:
>>
>>Fragment 1
>>
>>I once believed that domain names were =E2=80=9Cdot-separated alphanumeric word=
s=E2=80=9D
>>but learned otherwise while working on the so-labeled clarifications on
>>wild cards.  In order to being to understand how the DNS organism is
>>architected, one has to view this as a tree.  And, ironically as I deal
>>increasingly with non-ASCII identifiers, there=E2=80=99s no dot "on the wire.=E2=80=
=9D
>>(The root zone isn=E2=80=99t =E2=80=98.=E2=80=99, it=E2=80=99s a zero-valued byte.)
>>
>>
>>
>>
>>Good point.  The introduction in this document was to provide consistent
>>terminology sufficient to derive a model for understanding relationships
>>between domain names.  There is no talk of wire format, nor is there a
>>need to go into those semantics, as
>> this is all about namespace.  The representation in this document is
>>dot-separated labels. :)
>>=20
>>
>>
>>
>>In section 1.1.2 an overly simplified view is given.  Not all domains fit
>>neatly into the public and private bucket.  Some top-level-domains are
>>not
>>delegation only.
>>
>>
>>
>>
>>
>>For clarity, are you saying that for a single domain being public and
>>private are not mutually exclusive, or are you saying that top-level
>>domains are not all public?  I agree with the latter statement, and I'm
>>glad to offer more clarity in the document
>> if it is misleading in this regard.
>>
>>=20
>>
>>From these two comments my mind leads instantly into recommending that
>>this paper attempt to describe the problem from two very different
>>viewpoints.
>>
>>From the =E2=80=9Csystem-to-be-messed-with=E2=80=9D viewpoint, the nature of the DNS =
data
>>model as being first based on a tree structure must be respected as well
>>as a clear description of the management model based on the units of
>>zones.  The DNS protocol permits management of resource record sets,
>>domain (nodes) as well as zones but does not permit management of a
>>domain
>>(subtree).  (By the latter, I mean that DNS does not manage =E2=80=98across' a
>>zone cut.)
>>
>>
>>
>>
>>This is a valid point.  In this document I deliberately left zone cuts
>>out of the definitions.  The focus was on the problem of associating
>>namespaces, independent of zones.  Zone cut identification might be one
>>of the solutions considered, but even public/private
>> boundaries need not map consistently with zone cuts (in either
>>direction), so the problem is about namespace.
>>
>>
>>
>>
>>From the =E2=80=9Cpeople-having-a-problem-to-solve=E2=80=9D viewpoint, which you get =
to
>>in
>>1.1.3 and 1.1.4, I prefer replacing =E2=80=9Crelated=E2=80=9D with =E2=80=9Cequivalent=E2=80=9D f=
or a
>>specific purpose.  (I=E2=80=99ve said that before, no need to belabor it now.)
>>For one, you talk about a parent/child relationship but there=E2=80=99s really =
no
>>such thing as that.  A parent delegates the child, the child knows
>>nothing
>>about it=E2=80=99s parent - there=E2=80=99s no =E2=80=9Crelationship=E2=80=9D as far as the DNS p=
rotocol
>>is concerned.
>>
>>
>>
>>
>>Yes - but let's be clear that I'm establishing terminology for discussion
>>of namespace (not DNS protocol) for the purposes of this document.
>>=20
>>
>>
>>
>>Without giving this much thought, cross-domain relationships have been
>>historically significant, more so in operations than in the protocol.
>>The
>>co-mingling of dotCom and dotNet bear this out.
>>
>>I=E2=80=99m concerned about the problem set-up because, your chances of solving
>>the problem are better if you=E2=80=99ve properly set up the problem.
>>
>>
>>
>>
>>Agreed.
>>=20
>>
>>
>>
>>Fragment 2
>>
>>What=E2=80=99s missing from the PSL is a discussion of the registry behind the
>>PSL.  Looking strictly at the list of entries and concluding we just need
>>to make that work better is like saying a domain name registry is just a
>>DNS operator. I.e., how can you trust that the entries are legitimate?
>>
>>
>>
>>I can't tell if this is a general comment or something specific to the
>>document.  The problem statement document is not intended to assess the
>>content of the PSL--except to indicate the application of the model
>>described in previous sections in the paper (e.g.,
>> third paragraph of section 3).  The intent of the document is to define
>>the problem and identify existing solutions.  I make no conclusions.  The
>>question about the effectiveness of the PSL is partially addressed with
>>the second bullet under "problem statement"
>> in section 4.
>>
>>
>>
>>
>>Fragment 3
>>
>>This is not related directly to the document, but comes from =E2=80=9CCentraliz=
ed
>>vs. Distributed=E2=80=A6=E2=80=9D  One of the issues to think of is - how do we avoid
>>shared fate when we are looking for a new angle?  I.e., the DNS
>>distribution model is great for doing just what the PSL wants, but
>>placing
>>the PSL into the DNS is not helping.  Grossly arguing this way - if we
>>expect someone to try to register a child and use it to fool people using
>>the parent, what=E2=80=99s to stop the child from giving out fraudulent
>>information?  (This is a handwaving argument for why
>>what-ever-replaces-PSL should have some kind of separation from the DNS.)
>>
>>On the one hand, following the DNS tree is the best way to track who
>>knows
>>where the boundaries are.  On the other hand, that=E2=80=99s just the DNS
>>perspective talking.  And with only one source working here, we aren=E2=80=99t
>>making corrupting the system any harder than doing nothing at all.
>>
>>(I=E2=80=99m assuming that all of this is rooted in a security concern related =
to
>>the authorization of some information to be applied/accessed/etc.
>>Therefore, the talk about corrupting, fooling, fraudulent...)
>>
>>
>>
>>
>>
>>The scope of the problem statement is just that--a statement of the
>>problem.  These are valid considerations for solutions to the problem,
>>once the problem has been identified and defined.
>>
>>=20
>>
>>Fragment 4
>>
>>It=E2=80=99s possible that here are multiple goals here, with a common theme no=
t
>>clearly defined.  I see a desire to express the policies for a zone (not
>>a
>>domain) from the registry to a relying party.  This is one use case, not
>>the only, but one use case.  This is also expressed in a DNS viewpoint.
>>
>>The relying party applications I can=E2=80=99t speak as well for.
>>
>>Fragment 5
>>
>>I=E2=80=99m concerned about the mention of the gTLDs as being either =E2=80=9Ctoo muc=
h
>>detail=E2=80=9D or =E2=80=9Cnot enough detail.=E2=80=9D  The =E2=80=9Cnew class=E2=80=9D of TLDs is onl=
y special
>>in two respects - the rapidity that they appear and that they share a set
>>of operating principles.  If by grouping them you default to grouping
>>ccTLDs and legacy gTLDs, you haven=E2=80=99t made a useful categorization.  Unt=
il
>>we know what criteria we will use to divide the top-level domains, we
>>should hold off on this.
>>
>>
>>
>>
>>
>>
>>
>>It is admittedly brief and can be fleshed out, if it needs clarity.  The
>>intent was not to give a discourse on the new gTLDs or to make a grouping
>>or categorization, but simply recognize that as gTLDs: 1) they fall into
>>the "unbroken public scope from
>> the TLD" category and thus are pertinent to the discussion of the
>>problem (and solutions, including the PSL); 2) the total number of gTLDs
>>has (and will continue to) increased dramatically with the delegation of
>>the new gTLDs; and 3) their policies vary, just
>> as with previous gTLDs.  There are thus open questions of both
>>complexity and scalability that should be considered as the problem is
>>defined and solutions identified.
>>
>>
>>Cheers,
>>
>>Casey
>>
>>
>>
>>
>>

--B_3498045467_5343586
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSjTt8algUlgtI820Ft
sXq9xgEozTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDUyMDE3NDdaMA0GCSqGSIb3DQEBAQUABIIBAMf/W1Sr9d4geHHWdHLxLoggf0ZOWvzPI9+c
4V/1/XQ1KeJRz1UiCOqYD7Wlg6IY48F3Pm48uSl/+EZziaypx+P6vgjO9/qu7W8+vpbc4IZ1
81d2MMqwXHAqbePddNObxEpeSZTumEzUW7TLEYoSfEAoC1vRcz75F/OtUtQXtXlOPoYMb3Pe
s3Q4BkRZr0Uu8X3Z8rQo3Sicwzs9FhfuYjNfm4gbUX+qj9mFOVK8IXEyoE4Eef8bCMjJCwOZ
iaMUaBl/3pAX+FNi/sh5NpBAHG+SiAqNMaqP6xzan/bKRY7rVV/vKaQb2OANhEf/Px4wNAth
3PkSwfG+gmbqUJvYIFY=

--B_3498045467_5343586--


From nobody Wed Nov  5 12:54:01 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA21A87E9 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 12:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZlfZtANS37j for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 12:53:58 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5711ACD50 for <dbound@ietf.org>; Wed,  5 Nov 2014 12:53:57 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id y20so1541798ier.6 for <dbound@ietf.org>; Wed, 05 Nov 2014 12:53:57 -0800 (PST)
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-type; bh=gAhIaw9+0rlnU9zoCpndogC9+TvnRon+OWK9Knu6/D8=; b=iTQRlS57JWGBiWiZhHDHBN3pR87JSt6EYpoCDlKKqTXj7PedSoOwcc71xYhQZ/6Q/b vcI0fySKO88unTR8BW+URR+AMneX2Wmqtg//jKDOm9P2YIegI/oFPCquQcvIAvkmhQQX GGQQ2CTkBICEDzRluJTKG61aqdHkKfc0FNZVHixRX1cr3kYbsn8FVKLP343KYkWNeUmt +FoWFH6zVMlic6IYlknubkRCEtbV8CZ9xp9KFx5k8MsW630dtV849jnwmHMxGFEhyjr/ JW+/5cBi18apcXAb/V5PCPeC5ZuFYskmb2ryQOXgTivdol0pImScvWnSitLfKzcYh2O5 K4Mg==
MIME-Version: 1.0
X-Received: by 10.42.21.19 with SMTP id i19mr7016122icb.37.1415220837112; Wed, 05 Nov 2014 12:53:57 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Wed, 5 Nov 2014 12:53:56 -0800 (PST)
In-Reply-To: <20141105171908.GU30379@mx1.yitter.info>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com> <20141105171908.GU30379@mx1.yitter.info>
Date: Wed, 5 Nov 2014 15:53:56 -0500
Message-ID: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/uog9gzsYURljrP0nkU9oStLYM-w
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 20:53:59 -0000

On Wed, Nov 5, 2014 at 12:19 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> On Wed, Nov 05, 2014 at 12:15:04PM -0500, Jeffrey Walton wrote:
>> I'm interested in two boundaries. First, where are the gTLDs and
>> ccTLDs so I can perform a pre-flight check.
>
> I'd be interested to know what knowing those gains you.  (And is it
> that you want to know which are g and which cc, or just all the TLDs?)

The IETF does not forbid issuing a certificate for *.com, *.net and
friends. The CA/B Forums does forbid it. As a preflight check, I want
to reject those certificates categorically.

If a certificate passes the gTLD and ccTLD preflight check, then I am
willing to reach out over the network to learn of administrative
boundaries. (Or, I might just skip the administrative boundaries
check).

I'm not sure why the IETF feels its OK to issue a certificate for
*.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
seen any reasoning.


From nobody Wed Nov  5 13:47:35 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EA51A86FA for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level: 
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr6cjd-l1Z2x for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:47:31 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0821A86F8 for <dbound@ietf.org>; Wed,  5 Nov 2014 13:47:30 -0800 (PST)
Received: (qmail 10696 invoked from network); 5 Nov 2014 21:47:29 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Nov 2014 21:47:29 -0000
Date: 5 Nov 2014 21:47:07 -0000
Message-ID: <20141105214707.1557.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/NKNBetlcBkPKSmSqXOWxQevjJcU
Cc: noloader@gmail.com
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 21:47:32 -0000

>I'm not sure why the IETF feels its OK to issue a certificate for
>*.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
>seen any reasoning.

There are now vanity TLDs.  Why shouldn't a CA sign a cert for
*.neustar or *.williamhill if the TLD registrants (who are the same as
the registries) ask for them?

R's,
John

PS: Those are real TLDs, and I have the zone files to prove it.


From nobody Wed Nov  5 13:52:30 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD81A870C for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQOIaDRGzbQo for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:52:25 -0800 (PST)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CB51A870A for <dbound@ietf.org>; Wed,  5 Nov 2014 13:52:25 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id tp5so1682181ieb.22 for <dbound@ietf.org>; Wed, 05 Nov 2014 13:52:24 -0800 (PST)
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-type; bh=FtawWBeuFn/4kaoA2FJhVoZMM1jBHnBHla9bcyWgpEY=; b=JAAUnh+jEN1v/iO90dHE/c3YYCLgmZhhxz+cViuw+hXyLHR6IL92oeqA/kRt6I+5UX 4PQ/wNKxHJwCYdKYQRmekzQS4ne/WhUF3YMHs4jBiacWQi1KWZTrn//udubWy7uQ2djR TFnX0qxz1TVxyLINV0qRojkkTAazJZS0h5Jc13jmmg7mteQ36kYhCHFkq2qPtUSAf4mM xQlTdiQifS0O/VNCV9z70oSqSBOLaQZFQ+oqZL5iKR9IuQWPByNwrCDgZOL2VDHWpLsl IftxQWCTBexkchPNkgIy8N60tQhTCdcl5TR4ii6SPNeVBqyObad8Dh/OQQWHyC6p/hia tHYw==
MIME-Version: 1.0
X-Received: by 10.42.21.19 with SMTP id i19mr7297652icb.37.1415224344416; Wed, 05 Nov 2014 13:52:24 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Wed, 5 Nov 2014 13:52:24 -0800 (PST)
In-Reply-To: <20141105214707.1557.qmail@ary.lan>
References: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com> <20141105214707.1557.qmail@ary.lan>
Date: Wed, 5 Nov 2014 16:52:24 -0500
Message-ID: <CAH8yC8kC+_Mgj5k5Leq43rN6-ysvaRP=oQaK5rFt4_n7d_WjVw@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/BjnEGg6bEhmtaR20DE1AjTdIyfY
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 21:52:27 -0000

On Wed, Nov 5, 2014 at 4:47 PM, John Levine <johnl@taugh.com> wrote:
>>I'm not sure why the IETF feels its OK to issue a certificate for
>>*.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
>>seen any reasoning.
>
> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
> *.neustar or *.williamhill if the TLD registrants (who are the same as
> the registries) ask for them?
>
Good point John. The vanities need to be accounted for, too.

But its still not clear to me why the IETF feels its OK for someone to
to claim to issue *.com or *.net. Even the CA/B got that one right ;)


From nobody Wed Nov  5 13:55:07 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4301ACE2C for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3oglV3gqJqo for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 13:55:05 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64D11ACE26 for <dbound@ietf.org>; Wed,  5 Nov 2014 13:55:04 -0800 (PST)
Received: (qmail 11737 invoked from network); 5 Nov 2014 21:55:03 -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=2dd5.545a9cb7.k1411; bh=oh+1yeZg4cGdf7Ln4uEdFCpL+lGexRwPaark2NOopsw=; b=FQwonLLtTU9a+JU1g1c8etedI9B8LArGoapCtFDNiZapQu+CQLI1otlz0MI9vpeAzqF6ik7r7sWi0GaJvNiWW/B3oT+6aEHOmqRTVvZyVWTL+f0fcxLw7Joka3XINpg+S69tcrcPuFhGFGnjB7KuObnb/TXl69DtekHvEGoQjsOBaA0SyCbLakYhQrV6VzM2LgDnzKFhjXWaezfa91x/l5GBW+DFp9SFWQejVwbiyX8x1T4w8+TcHKL5zU7+Wki9
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=2dd5.545a9cb7.k1411; bh=oh+1yeZg4cGdf7Ln4uEdFCpL+lGexRwPaark2NOopsw=; b=dUYricw2wUAZtfUWxIT6356TP/NFKkyZfLinUgoVHAl4yVenFX4spMCqr7N+Qx653r9uWAZZr3M044qGKKyq5vOW44DIuunEb1a/C3qFIVQVtg3HDawoHBpMAb9WUDGv6rlPgwtvPWvcRwQ1teAMyaUX7zWbgx3fgP/Gvz+jdZnrJPynfS4p1S9AKqbw981p1Lq7iO+utDOknaJG5XINxbiqKlxD8ho1QFTfHmJGhEoeTO2Q2iUKasnTsE7zpz5S
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; 05 Nov 2014 21:55:03 -0000
Date: 5 Nov 2014 16:55:02 -0500
Message-ID: <alpine.OSX.2.11.1411051654250.26557@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Jeffrey Walton" <noloader@gmail.com>
In-Reply-To: <CAH8yC8kC+_Mgj5k5Leq43rN6-ysvaRP=oQaK5rFt4_n7d_WjVw@mail.gmail.com>
References: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com> <20141105214707.1557.qmail@ary.lan> <CAH8yC8kC+_Mgj5k5Leq43rN6-ysvaRP=oQaK5rFt4_n7d_WjVw@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/ubWXAeQ5Iqvvw6QOLa62ia-x7N8
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 21:55:06 -0000

>> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
>> *.neustar or *.williamhill if the TLD registrants (who are the same as
>> the registries) ask for them?
>>
> Good point John. The vanities need to be accounted for, too.
>
> But its still not clear to me why the IETF feels its OK for someone to
> to claim to issue *.com or *.net. Even the CA/B got that one right ;)

The IETF writes technical specs.  What's the technical difference between 
*.com and *.neustar?

(I realize there is a significant administrative difference.)

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Wed Nov  5 14:25:38 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D319D1A002A for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 14:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaJARSZ3ld0r for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 14:25:34 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC101A0023 for <dbound@ietf.org>; Wed,  5 Nov 2014 14:25:33 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 5 Nov 2014 14:25:32 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Wed, 5 Nov 2014 14:25:32 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: John R Levine <johnl@taugh.com>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAV+8AgAAW9ICAAA6jAIAABrcAgAABIwCAADwDAIAADtyAgAABegCAAAC9AP//gmnf
Date: Wed, 5 Nov 2014 22:25:31 +0000
Message-ID: <1930CD72-4535-4B0C-B850-4D382A162FE9@icann.org>
References: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com> <20141105214707.1557.qmail@ary.lan> <CAH8yC8kC+_Mgj5k5Leq43rN6-ysvaRP=oQaK5rFt4_n7d_WjVw@mail.gmail.com>, <alpine.OSX.2.11.1411051654250.26557@ary.lan>
In-Reply-To: <alpine.OSX.2.11.1411051654250.26557@ary.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/gFbYwULwmL4edE6tTDcf5cMEStY
Cc: Jeffrey Walton <noloader@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 22:25:37 -0000

The global public internet is not the only inter-network using tcp/ip or DN=
S.=20



Sent from my iPhone

On Nov 5, 2014, at 16:55, John R Levine <johnl@taugh.com> wrote:

>>> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
>>> *.neustar or *.williamhill if the TLD registrants (who are the same as
>>> the registries) ask for them?
>> Good point John. The vanities need to be accounted for, too.
>>=20
>> But its still not clear to me why the IETF feels its OK for someone to
>> to claim to issue *.com or *.net. Even the CA/B got that one right ;)
>=20
> The IETF writes technical specs.  What's the technical difference between=
 *.com and *.neustar?
>=20
> (I realize there is a significant administrative difference.)
>=20
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


From nobody Wed Nov  5 15:11:41 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EE61A0194 for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 15:11:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo_GvqDZqMBF for <dbound@ietfa.amsl.com>; Wed,  5 Nov 2014 15:11:35 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5574B1A00B5 for <dbound@ietf.org>; Wed,  5 Nov 2014 15:11:35 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C2FEC8A035 for <dbound@ietf.org>; Wed,  5 Nov 2014 23:11:33 +0000 (UTC)
Date: Wed, 5 Nov 2014 18:11:32 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141105231131.GJ31320@mx1.yitter.info>
References: <CAEKtLiR+_tL0xvX-SXi2p7YxeaskSgwZb9_RZRF45mKS0aFHXQ@mail.gmail.com> <20141105165102.81434.qmail@ary.lan> <CAH8yC8=tZGxwg7OjBvV4z0Xyn1mpXMAtHb9xLk4wh0YeuQGAtg@mail.gmail.com> <20141105171908.GU30379@mx1.yitter.info> <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH8yC8=HhMG+oRqNktCasU8_cn6V_eF4N6+kkFw3EMstvv2MjA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oPTr2JuHGmcHWAJQr8CAm_8kXbA
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 23:11:39 -0000

On Wed, Nov 05, 2014 at 03:53:56PM -0500, Jeffrey Walton wrote:
> friends. The CA/B Forums does forbid it. As a preflight check, I want
> to reject those certificates categorically.

Ok, but aren't there other ones you also want to reject?  For
instance, it'd be at least just as bad to get *.co.uk.  That's not a
TLD.

If you respond, "Oh, but it's an _effective_ TLD," then you're
basically granting my point: the issue is not where in the hierarchy
you stand, but in what relationship you stand with everything else.
_One_ of those relationships is, "Always administrative delegation;
maybe not DNS delegation; no other administrative sharing."  That's
basically what people mean by "public suffix."  And I think we should
expect that various different models of this get more common as more
new TLDs come online and realise their business model is doomed.

Now, if you're saying, "Oh, but I need some of this to be cached on my
side," I agree.  That's really just a requirement for
effectively-infinite TTLs, however.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Thu Nov  6 09:27:32 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1CE1A8897 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 09:27:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlKjUFh8kM1E for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 09:27:25 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879231A8895 for <dbound@ietf.org>; Thu,  6 Nov 2014 09:27:25 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id tr6so3420183ieb.18 for <dbound@ietf.org>; Thu, 06 Nov 2014 09:27:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:date:message-id:subject:from:to:content-type; bh=YOcuSEPo0qkK/MCwDfeAjjtUxRl1C+eoKhwRJNC9a7o=; b=Mh3LiSxWAk/hBnrhuWhOBwJywNxvvNPdKrLUj2c3h02+3ib18Qf6GbsKGn/5w52VIi JqtVCQjLKKnHxK0FsdSSKPf4ZaItOp43Q3ldqKVIXAImxAAfkuIKqLcQTfQHXagGlsYg UT8ILRSy476VTsI8qAfxHSqvwdpPgn9uMqq6o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YOcuSEPo0qkK/MCwDfeAjjtUxRl1C+eoKhwRJNC9a7o=; b=fJR2DemJUMHf6GHXhjUpontG9Q2lrxVVIFZ9IXfzVSQOdNgzoOapg8sufvdQdJmFNw cu7psxP+4H9SA3wZ2Jr0vmJhcF0kyomo5oaW2MbR0NnL1bAw9C5u/Ykqk2cofTSA3vKX lZL8pGAy7bNMCAC/ZmcNB1FfbNYBLNlxFX9zABL9lqdeZgGhZiYKiBjQQK9JFGKwxGv+ B+7lEuL5rhlEc+YBjw0QrWbMtyqZHspVqD6q2txRMAlXaWiBxN60SgqRcJqHrQ0HOp9f GqAAm76fXec/whSHxGO2WQlnDlZTYdIz0NHLRFG/NI6dKh9swGgHJ0VCztZ+vsuD3uwn rZHQ==
X-Gm-Message-State: ALoCoQm8amjda/biqBnxXiyZV5v786nk9t6/ZcRDm2x3kLD9x7ce0XxNHDLJoEOwBYagWJ9Qf5P2
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr4507971ioo.73.1415294844702; Thu, 06 Nov 2014 09:27:24 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Thu, 6 Nov 2014 09:27:24 -0800 (PST)
Date: Thu, 6 Nov 2014 12:27:24 -0500
Message-ID: <CAEKtLiTmLTroLkZ5aM-1s-6f=tEyNCWj=kjED7vaKf31ovTwog@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a113703b478ad0705073402bf
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Qspp8x8DhL-6Q5pS-8zWfsBIvLE
Subject: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 17:27:31 -0000

--001a113703b478ad0705073402bf
Content-Type: text/plain; charset=UTF-8

A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.

The objectives of the meeting are to review the principles and background
behind domain boundaries, identify applications and protocols for which
there is demand for such, and come up with a problem statement.  Since I've
called for the BoF, I'll come up with a loose agenda for accomplishing
this, but I'm happy to take feedback and suggestions from other interested
parties.  I plan to use the proposed draft problem statement [1] as a
starting place.

Best regards,
Casey

[1] http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html

--001a113703b478ad0705073402bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A DBOUND bar BoF (i.e., unofficial IETF meeting) will be h=
eld Tuesday morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.<b=
r><br>The objectives of the meeting are to review the principles and backgr=
ound behind domain boundaries, identify applications and protocols for whic=
h there is demand for such, and come up with a problem statement.=C2=A0 Sin=
ce I&#39;ve called for the BoF, I&#39;ll come up with a loose agenda for ac=
complishing this, but I&#39;m happy to take feedback and suggestions from o=
ther interested parties.=C2=A0 I plan to use the proposed draft problem sta=
tement [1] as a starting place. <br><br>Best regards,<br>Casey<br><br>[1] <=
a href=3D"http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html=
">http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html</a><br>=
</div>

--001a113703b478ad0705073402bf--


From nobody Thu Nov  6 09:31:17 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0CA1A88B0 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 09:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QDkHr0GQq2V for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 09:31:14 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C301A88A6 for <dbound@ietf.org>; Thu,  6 Nov 2014 09:31:14 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id at20so3432701iec.31 for <dbound@ietf.org>; Thu, 06 Nov 2014 09:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uoifDpIjIOuDtzHIdYH8BqRcNZr1807KK4jMddpSWLA=; b=XaER5nxr0j3vSlt3yuPpQV9dupIDTDELKOC+IjWUgDWQSg+vLTV31APBlYM7Bp8hMj joWuRiMu4aD2mT3HFsiwRC7Qn2uzdRbPywOQUnl97B/AwUd7bZ1j+hmaxr3JvazeU3Vt WBz4CjGbHXv5rl5TIhZjvPVBrSaQpprl3tyeM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=uoifDpIjIOuDtzHIdYH8BqRcNZr1807KK4jMddpSWLA=; b=did1N3s27D2pFlbY/zn6jJ0+Q/HLM6ps+lwnNEUs+4/9jI29RxV/mwP/ZN+6VfZ0kC EIftyg8TKUBPAtIt6jDWH9Fr0Z5QPzql9JH0MoImHnAaodBSb0Vo7aat2FlSNkfMdyv9 vnMBUridb3d/ksN+DRgW4ZCOluWb4fB5mG+qbMd/lCDT55Y2HO72qDWb4X9K1h/+opok YSuSKoZ4AGpAIabfFR2Idsmo395u5EQBi7AxuKfURsaML8tTsQtiENYZAka1vwSYJ4/J WHJ5pv1mv8+MsxCx2koE760H67LCRC3WEf1jVxYo2ndz3BgI0S9FiLIF9oY6n4EaIaA1 021g==
X-Gm-Message-State: ALoCoQnDoHYhK9LqG5zCLswsRCYjVoGBxUI0JJdm2JQ5uk1irv/AWhac/1F3jo0cQfkk2rJWgJM7
MIME-Version: 1.0
X-Received: by 10.50.3.97 with SMTP id b1mr14412544igb.12.1415295073152; Thu, 06 Nov 2014 09:31:13 -0800 (PST)
Received: by 10.50.251.178 with HTTP; Thu, 6 Nov 2014 09:31:13 -0800 (PST)
In-Reply-To: <CAEKtLiTmLTroLkZ5aM-1s-6f=tEyNCWj=kjED7vaKf31ovTwog@mail.gmail.com>
References: <CAEKtLiTmLTroLkZ5aM-1s-6f=tEyNCWj=kjED7vaKf31ovTwog@mail.gmail.com>
Date: Thu, 6 Nov 2014 12:31:13 -0500
Message-ID: <CAEKtLiQcjKTryJzTS76EYp8jF=irwk6TnBSQ1nAhSVJyi2kPrA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=089e013cc32c16b09d0507341005
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/rPAX_Vzt2AtNmLP8K41mmHi_zdo
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 17:31:16 -0000

--089e013cc32c16b09d0507341005
Content-Type: text/plain; charset=UTF-8

One other note.  The capacity of the room is relatively small (~20), but I
received very few RSVPs.  If that number is any indicator, then room size
shouldn't be a problem.

Cheers,
Casey

On Thu, Nov 6, 2014 at 12:27 PM, Casey Deccio <casey@deccio.net> wrote:

> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
>
> The objectives of the meeting are to review the principles and background
> behind domain boundaries, identify applications and protocols for which
> there is demand for such, and come up with a problem statement.  Since I've
> called for the BoF, I'll come up with a loose agenda for accomplishing
> this, but I'm happy to take feedback and suggestions from other interested
> parties.  I plan to use the proposed draft problem statement [1] as a
> starting place.
>
> Best regards,
> Casey
>
> [1] http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html
>

--089e013cc32c16b09d0507341005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>One other note.=C2=A0 The capacity of the room is rel=
atively small (~20), but I received very few RSVPs.=C2=A0 If that number is=
 any indicator, then room size shouldn&#39;t be a problem.<br><br></div><di=
v>Cheers,<br></div>Casey <br><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Thu, Nov 6, 2014 at 12:27 PM, Casey Deccio <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@deccio.net=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">A=
 DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday mornin=
g 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.<br><br>The objectiv=
es of the meeting are to review the principles and background behind domain=
 boundaries, identify applications and protocols for which there is demand =
for such, and come up with a problem statement.=C2=A0 Since I&#39;ve called=
 for the BoF, I&#39;ll come up with a loose agenda for accomplishing this, =
but I&#39;m happy to take feedback and suggestions from other interested pa=
rties.=C2=A0 I plan to use the proposed draft problem statement [1] as a st=
arting place. <br><br>Best regards,<br>Casey<br><br>[1] <a href=3D"http://w=
ww.ietf.org/mail-archive/web/dbound/current/msg00087.html" target=3D"_blank=
">http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html</a><br>=
</div>
</blockquote></div><br></div></div>

--089e013cc32c16b09d0507341005--


From nobody Thu Nov  6 13:34:00 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308321A8ADF for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 13:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2OrGyKZ-G4p for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 13:33:54 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 4A8A41A70FD for <dbound@ietf.org>; Thu,  6 Nov 2014 13:33:54 -0800 (PST)
Received: (qmail 17356 invoked by uid 0); 6 Nov 2014 21:33:49 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 6 Nov 2014 21:33:49 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with  id CTZf1p0172UhLwi01TZi5e; Thu, 06 Nov 2014 20:33:48 -0700
X-Authority-Analysis: v=2.1 cv=b7chvL2x c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=ej1aznjVFi3k8UmJlaMA:9 a=QEXdDO2ut3YA:10 a=8q71qWnZ9u4A:10 a=iwjcJBIuu-oA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PE13S0P2WAh9zesmXwuc7j6eLS88MRALJF+UdBGrBjI=;  b=NaK19Nh0XDuQOSXFA+tP8Er8ZSRUQsMB7eD9mW8NYy+WV5ye9O1dZ0RM3sIyGdbU0OlzxKOcU93ix6odnC8uApB3c8pwzpA730CYGwdssmdabX6pjAqB3aZzZZfiXbbl;
Received: from [24.5.2.144] (port=52023 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XmUgW-0001cT-9s; Thu, 06 Nov 2014 14:33:40 -0700
Message-ID: <545BE95F.3080601@KingsMountain.com>
Date: Thu, 06 Nov 2014 13:34:23 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/YHIWSPCvCsKsbiNgCBkVAPO4vEM
Cc: dbound@ietf.org
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 21:33:55 -0000

 > A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
 > morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.

well, I'd like to participate but need to also attend UTA which is in that 
timeslot (based on UTA agenda I can perhaps skip the first hour of UTA 
unless they run ahead of schedule).

how come a daytime slot and not an evening get-together? (but then y'all 
shouldn't make changes just for a slacker like me)

thanks,

=JeffH



From nobody Thu Nov  6 13:50:34 2014
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC41A90CB for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 13:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ianbfq0X8EM7 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 13:50:31 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD981A90C9 for <dbound@ietf.org>; Thu,  6 Nov 2014 13:50:31 -0800 (PST)
Received: from [10.70.10.71] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id BE4FBF984 for <dbound@ietf.org>; Thu,  6 Nov 2014 16:50:28 -0500 (EST)
Message-ID: <545BED22.8070406@fifthhorseman.net>
Date: Thu, 06 Nov 2014 16:50:26 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0
MIME-Version: 1.0
To: dbound@ietf.org
References: <545BE95F.3080601@KingsMountain.com>
In-Reply-To: <545BE95F.3080601@KingsMountain.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e8UKrUtqGieo8nOJelDiOe6faEDu1GPQM"
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/0J14U6-jkjbsX45OAIF0ir-kMLQ
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 21:50:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--e8UKrUtqGieo8nOJelDiOe6faEDu1GPQM
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/06/2014 04:34 PM, =3DJeffH wrote:
>> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
>> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
>=20
> well, I'd like to participate but need to also attend UTA which is in
> that timeslot (based on UTA agenda I can perhaps skip the first hour of=

> UTA unless they run ahead of schedule).
>=20
> how come a daytime slot and not an evening get-together? (but then y'al=
l
> shouldn't make changes just for a slacker like me)

I'm also going to have to prioritize UTA over a DBOUND BoF.  planning a
BoF like this during scheduled non-BoF meetings seems not so good.

	--dkg


--e8UKrUtqGieo8nOJelDiOe6faEDu1GPQM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJUW+0iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcC74QAOjok1FD4U7EF/n5A8iHRaZh
6etjKsc6J6yWSsmXl1voDFv5T0odQL4TQgSDVE4Y+bokwgAWyF8hOJQIGjEFfjTC
K9Y9S1rH3lHGc+eXfFfEldVjSBi0J6v+nVecHANUvOuOzcz9uYslZ95QRfg410Ez
aF01dlfsAcK3kaA04XCcY1oDXfTTyu5iPBgtFXosROqQ3EGg79T+r/5RicxzFgvQ
behhc14qeMX6TEgnfF0D/Z18j9R3Wq73BC58PA69CroULg5gW1raGilyKMSXMWNb
3V1jsVGpvxIFfaa0/fMl+W6HNcSmuJbhplrvid/Vx8yqy/NGlhHOiFNMp8ncsQLd
6VtU+thQ9ppTDUo2n4Fw2vX3uFfJXW5Ng7cVFj6CdTRRxDoOVESo8vQ2JsWK4b/R
ksLSvKRjjizmAidBUoPHv785T4Jyhncw+pluIN6CT6MvVnIJU4OnnnJr5yCYMvil
eJtS13hmUUxWS1IfNCm/rbSpSJA0tsDSF21iFJNXn0H4QgclsqVDRZ36f0xHm3zB
c08ziTOIZsDm8pUoQjGmAuM/0JFIoPA6XFTrM360lNN6G9p4sb1Vm/fOZ6Jybev9
1Gp8ezeJxd6K/83ZKbx2VZwrcULd1RbNqzC76AIrXFUZIpSaxQIe0y5t1ONlXU4Y
ycdSGBFZ/xOeHAdHfyIU
=xk+t
-----END PGP SIGNATURE-----

--e8UKrUtqGieo8nOJelDiOe6faEDu1GPQM--


From nobody Thu Nov  6 14:06:38 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE761A916A for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 14:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BYPx4mM5ed6 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 14:06:34 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D57A1A9166 for <dbound@ietf.org>; Thu,  6 Nov 2014 14:06:34 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id rp18so4017251iec.9 for <dbound@ietf.org>; Thu, 06 Nov 2014 14:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+xxToRjsu855C467RuVoU9y/ZyZZTFn1L+3CO5cJXYI=; b=BVNsMZlP1g7sd0cBWOnnWu8j6Kl8nh5iI3Ipf+kvGgg23Ac1VfMXhcNWNn5dYgN6Hb ri/xghlmXmn1j7UuS0KO8qHZpM6d6zNdI3BeW4PH5z0YN2wCkOvjRNIaU5teztrFuZBR mgvBdwas9tudzJFbrCOOEdcib3wbqOf0zwDFs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+xxToRjsu855C467RuVoU9y/ZyZZTFn1L+3CO5cJXYI=; b=ATHo+RVfjriffaWMom68xDDfS/pwYsFmXy02AkMFc8BNCftKQ5VtIbIyR7GwtSfppo xdBJNU135wdq7T3/wa67vabw2jHm5nesDA9F+KLUWVk00S8qOEoO0Lj1vZS9AhDQKSW9 zLvSeIdP4kQK/5HSj84Sble4YlVWW8ilM190kNXE/YJSi6q17IgHW8SWdJQEsd7fSCAc CY30CV0Kyp5xOsl+XQRR+bWdbJ2aN8ANEMbbZYY0h2iUK2mxULzeYGaNzuf1588hhzrg jla1vLsdFQr1xq7gHNqn0JjfGq+Yj9oRoOMu0mfIde5wX8cArcBDfDHcnBB0vlhoIjjG PXKw==
X-Gm-Message-State: ALoCoQnHTeWnRxXh3OksvYM/0zMftHIBu/YifYgD9X3UqPKDHcs2O277eExSCSae5whUMYHQBQ5R
MIME-Version: 1.0
X-Received: by 10.50.3.97 with SMTP id b1mr16157158igb.12.1415311593354; Thu, 06 Nov 2014 14:06:33 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Thu, 6 Nov 2014 14:06:33 -0800 (PST)
In-Reply-To: <545BED22.8070406@fifthhorseman.net>
References: <545BE95F.3080601@KingsMountain.com> <545BED22.8070406@fifthhorseman.net>
Date: Thu, 6 Nov 2014 17:06:33 -0500
Message-ID: <CAEKtLiSe5KOmqaSqkgPUaq-egZRtt0if8mxxSirdsybAgoqw6A@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary=089e013cc32cc4d5cf050737e816
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/RRM6PJ--XIQThz7jlBUHHatXdfY
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 22:06:36 -0000

--089e013cc32cc4d5cf050737e816
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 6, 2014 at 4:50 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> On 11/06/2014 04:34 PM, =JeffH wrote:
> >> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
> >> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
> >
> > well, I'd like to participate but need to also attend UTA which is in
> > that timeslot (based on UTA agenda I can perhaps skip the first hour of
> > UTA unless they run ahead of schedule).
> >
> > how come a daytime slot and not an evening get-together? (but then y'all
> > shouldn't make changes just for a slacker like me)
>
> I'm also going to have to prioritize UTA over a DBOUND BoF.  planning a
> BoF like this during scheduled non-BoF meetings seems not so good.
>

The conflict with non-BoF meetings that would make DBOUND-interested
participants have to choose was, of course, unintentional.  The meeting
time is not set in stone, and if there's sufficient interest/demand to move
it to another time (or hold a "true" BoF), that could be arranged.  I was
simply looking first for daytime slots where it would not conflict, with
evening slots being a fallback--to maximize use of the day.  That was the
intent of my call for interest and conflict earlier in the week.

That being said, there will likely always be some conflict for someone,
whether it's day or evening.

Casey

--089e013cc32cc4d5cf050737e816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Nov 6, 2014 at 4:50 PM, Daniel Kahn Gillmor <span =
dir=3D"ltr">&lt;<a href=3D"mailto:dkg@fifthhorseman.net" target=3D"_blank">=
dkg@fifthhorseman.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEn=
Zb"><div class=3D"h5">On 11/06/2014 04:34 PM, =3DJeffH wrote:<br>
&gt;&gt; A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tues=
day<br>
&gt;&gt; morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.<br>
&gt;<br>
&gt; well, I&#39;d like to participate but need to also attend UTA which is=
 in<br>
&gt; that timeslot (based on UTA agenda I can perhaps skip the first hour o=
f<br>
&gt; UTA unless they run ahead of schedule).<br>
&gt;<br>
&gt; how come a daytime slot and not an evening get-together? (but then y&#=
39;all<br>
&gt; shouldn&#39;t make changes just for a slacker like me)<br>
<br>
</div></div>I&#39;m also going to have to prioritize UTA over a DBOUND BoF.=
=C2=A0 planning a<br>
BoF like this during scheduled non-BoF meetings seems not so good.<br>
<span class=3D"HOEnZb"></span></blockquote><div><br></div><div>The conflict=
 with non-BoF meetings that would make DBOUND-interested participants have =
to choose was, of course, unintentional.=C2=A0 The meeting time is not set =
in stone, and if there&#39;s sufficient interest/demand to move it to anoth=
er time (or hold a &quot;true&quot; BoF), that could be arranged.=C2=A0 I w=
as simply looking first for daytime slots where it would not conflict, with=
 evening slots being a fallback--to maximize use of the day.=C2=A0 That was=
 the intent of my call for interest and conflict earlier in the week.<br><b=
r></div><div>That being said, there will likely always be some conflict for=
 someone, whether it&#39;s day or evening.<br></div><div><br></div><div>Cas=
ey<br></div></div></div></div>

--089e013cc32cc4d5cf050737e816--


From nobody Thu Nov  6 20:09:58 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014381A0363 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 20:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-af0Wp_J-VQ for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 20:09:41 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE751A0125 for <dbound@ietf.org>; Thu,  6 Nov 2014 20:09:40 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id gf13so3823844lab.17 for <dbound@ietf.org>; Thu, 06 Nov 2014 20:09:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8wuzV/kOBuDHyyVnFxONavPuH32dtJapWYPvbfx5sgE=; b=epJ9Rmp7EvEmE0Nm63lEZ3MdOOEajgkzp/aUPQ8bj7r0+lrfHUSNde1+vRkbisOHk+ I0CugaWKYBIkZ5BFEQM2dwaWxIaiHMUSdG7Rc8U6PXxt8WD9ef/UYGYTZUCGJ/qJcOny vYXJCJVMyVyWExEgT09PFHfOVH1yrkxfRlWVwT1nY+DFRueBSpuxrVSmOpsz/LEwUc+w TsOSDL9NLsdf39ZBgamXW8X38942eL1supVH2G9v7VkOJzckrKyOJytuwCqHGckod9Jk c1I47fyeluP+onKDutKOOpi0swIaLV5YnjfGzvw9+mTa1vyFoaovKSHfpqJr9IyTpIxF Jx1A==
X-Gm-Message-State: ALoCoQkI+ZXSFj0kNREaWizm4yJ+OfPQtRL8zUc6PDyqvYYAVF2QTS//aJ1L8TXfz2Os4Qc0pUGp
MIME-Version: 1.0
X-Received: by 10.112.137.39 with SMTP id qf7mr8665333lbb.47.1415333379238; Thu, 06 Nov 2014 20:09:39 -0800 (PST)
Received: by 10.25.170.194 with HTTP; Thu, 6 Nov 2014 20:09:39 -0800 (PST)
In-Reply-To: <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan> <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com> <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com>
Date: Thu, 6 Nov 2014 20:09:39 -0800
Message-ID: <CAGrS0FK+JE2nnniq9Ax=X4DGEpgDD1_mz_VxWmb-8PX1Oc1xVQ@mail.gmail.com>
From: Jothan Frakes <jothan@jothan.com>
To: dbound@ietf.org
Content-Type: multipart/alternative; boundary=089e011609cc4f078605073cfb06
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TczphKnlNegqTU4S_W5JSwuWmZI
Cc: Jeffrey Walton <noloader@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, casey@deccio.net, John R Levine <johnl@taugh.com>
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 04:09:44 -0000

--089e011609cc4f078605073cfb06
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I see the IANA TLD list as the alpha PSL or "patient zero" for things
that this DBOUND effort might enhance a structure around.  Anything that
extends details within that list is within scope.  Though that list is a
text file which perpetuates the hosts.txt issue, I refer to it more as a
resource than a file.

There is some review of "public suffix lists" like the IANA TLD list and
the Public Suffix List that is maintained by Mozilla under way, where there
is debate over the definition of "public"... in the context of "public
suffix list".

A) A list, such as the IANA TLD list or Mozilla PSL, which contains things
that behave as though they are a "TLD", which is accessible to the public

B) A region of public (root-down, trusted origination and administrative
realm) within a list of things that behave as though they are a "TLD",
followed by a region within that list that are self-nominated suffixes
after the defined top-down boundary.

It seems to me that dbound efforts work with definition a and b.  I have
heard robust energy that it might be "a" or "b".  I don't wish to constrain
the definition of public suffix list to those two either as there are
likely others, given the different angles we are looking at this through.

I do think that by leaving this aspect of the dialog undefined or loosely
defined, and working without a foundation, efforts to create any standards
may be challenging.  So far, I see different people putting forth great
ideas that work within their definition realm of "public suffix", yet some
of those great ideas stray into the realm of the obtuse when someone with a
slightly different definition looks at them from their point of view.

As pedantic as this sounds, I would encourage we think through and perhaps
identify a common vocabulary and definition of "Suffix".  Even if we define
them commonly within the role of the perspective (I.e. To a DNS
administrator, it means X, to law enforcement or anti-spam integrator it
means Y, to a software developer who is seeking to validate user input it
means Z, etc) I suspect this will aid the effort of the problem statement.

-jothan



On Tuesday, November 4, 2014, Casey Deccio <casey@deccio.net> wrote:

> Hi Suzanne,
>
> On Tue, Nov 4, 2014 at 9:09 AM, Suzanne Woolf <suzworldwide@gmail.com
> <javascript:_e(%7B%7D,'cvml','suzworldwide@gmail.com');>> wrote:
>
>> Reviewing assorted things for IETF 91=E2=80=A6.
>>
>> Has there been progress on the problem statement we discussed in Toronto=
?
>
>
>
>> I may have more time now than I did then for this work, and would like t=
o
>> pitch in.
>>
>>
> Progress was slower than I had anticipated in the last message that I sen=
t
> on the subject.  But, I have a draft problem statement, which I'll send o=
ut
> shortly in another email.  I'm hoping to organize a bar BoF to discuss,
> revise, and refine the draft problem statement.
>
> Casey
>


--=20

Jothan Frakes
Tel: +1.206-355-0230

--089e011609cc4f078605073cfb06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<font><span style=3D"background-color:rgba(255,255,255,0)">I see the IANA T=
LD list as the alpha PSL or=C2=A0&quot;patient zero&quot; for things that=
=C2=A0this DBOUND effort=C2=A0might enhance a structure around.=C2=A0 Anyth=
ing that extends details within that list is within scope.=C2=A0 Though tha=
t list is a text file which perpetuates the hosts.txt issue, I refer to it =
more as a resource than a file.<br><br></span></font><div><font><span style=
=3D"background-color:rgba(255,255,255,0)">There is some review of &quot;pub=
lic suffix lists&quot;=C2=A0like the IANA TLD list and the Public Suffix Li=
st that is maintained by Mozilla under way, where there is debate over the =
definition of &quot;public&quot;... in the context of &quot;public suffix l=
ist&quot;.</span></font><div><div><font><span style=3D"background-color:rgb=
a(255,255,255,0)"><br></span></font></div><div><font><span style=3D"backgro=
und-color:rgba(255,255,255,0)">A)=C2=A0</span></font><span style=3D"backgro=
und-color:rgba(255,255,255,0);font-size:small">A</span><span style=3D"backg=
round-color:rgba(255,255,255,0);font-size:small">=C2=A0</span><span style=
=3D"background-color:rgba(255,255,255,0);font-size:small">list, such as the=
 IANA TLD list or Mozilla PSL,=C2=A0which contains=C2=A0things that behave =
as though they are a &quot;TLD&quot;,=C2=A0which is accessible to the publi=
c</span></div><div><font><span style=3D"background-color:rgba(255,255,255,0=
)"><br></span></font></div><div><font><span style=3D"background-color:rgba(=
255,255,255,0)">B)=C2=A0</span></font><span style=3D"background-color:rgba(=
255,255,255,0);font-size:small">A region of public (root-down,=C2=A0trusted=
 origination and administrative realm)=C2=A0within a=C2=A0list of things th=
at behave as though they are a=C2=A0&quot;TLD&quot;, followed by a region w=
ithin that list=C2=A0that are self-nominated suffixes after the=C2=A0define=
d top-down boundary.</span></div><div><br></div><div><font><span style=3D"b=
ackground-color:rgba(255,255,255,0)">It seems to me that dbound efforts wor=
k with definition a and b.=C2=A0 I have heard robust energy that it might=
=C2=A0be=C2=A0&quot;a&quot; or &quot;b&quot;.=C2=A0 I don&#39;t wish to con=
strain the definition of public suffix list=C2=A0to those two either=C2=A0a=
s there are likely others, given the different angles we are looking at thi=
s through.=C2=A0</span></font></div><div><font><span style=3D"background-co=
lor:rgba(255,255,255,0)"><br></span></font></div><div><font><span style=3D"=
background-color:rgba(255,255,255,0)">I do=C2=A0think that=C2=A0by leaving =
this aspect of the dialog undefined or loosely defined, and working without=
 a foundation,=C2=A0efforts to create=C2=A0any standards may be challenging=
.=C2=A0 So far, I see different people putting forth great ideas that work =
within their definition realm of &quot;public suffix&quot;, yet some of=C2=
=A0those great=C2=A0ideas stray into the realm of the obtuse=C2=A0when some=
one with a slightly different definition looks at them from their point of =
view.</span></font></div></div></div><div><font><span style=3D"background-c=
olor:rgba(255,255,255,0)"><br></span></font></div><div><font><span style=3D=
"background-color:rgba(255,255,255,0)">As pedantic as this sounds, I would =
encourage we think through and perhaps identify a common vocabulary and def=
inition of &quot;Suffix&quot;.=C2=A0 Even if we define them commonly within=
 the role of the perspective (I.e. To a DNS administrator, it means X, to l=
aw enforcement or anti-spam integrator it means Y, to a software developer =
who is seeking to validate user input it means Z,=C2=A0etc) I suspect this =
will aid the effort of the problem statement.</span></font></div><div><font=
><span style=3D"background-color:rgba(255,255,255,0)"><br></span></font></d=
iv><div>-jothan</div><div><br></div><div><font><span style=3D"background-co=
lor:rgba(255,255,255,0)"><br></span></font></div><div><div><div><div><div><=
br>On Tuesday, November 4, 2014, Casey Deccio &lt;<a href=3D"mailto:casey@d=
eccio.net">casey@deccio.net</a>&gt; wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Hi Suzanne,<br><div><br>On Tue, Nov 4, 2014 at 9:09 AM, =
Suzanne Woolf <span dir=3D"ltr">&lt;<a href=3D"javascript:_e(%7B%7D,&#39;cv=
ml&#39;,&#39;suzworldwide@gmail.com&#39;);" target=3D"_blank">suzworldwide@=
gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Reviewing a=
ssorted things for IETF 91=E2=80=A6.<br>
<br>
Has there been progress on the problem statement we discussed in Toronto?</=
blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
I may have more time now than I did then for this work, and would like to p=
itch in.<br>
<br></blockquote><div><br>Progress
 was slower than I had anticipated in the last message that I sent on=20
the subject.=C2=A0 But, I have a draft problem statement, which I&#39;ll se=
nd out shortly in another email.=C2=A0 I&#39;m hoping to organize a bar BoF=
 to discuss, revise, and refine the draft problem statement.<br><br></div><=
div>Casey<br></div></div></div></div></div>
</blockquote></div></div></div></div></div><br><br>-- <br><div dir=3D"ltr">=
<br>Jothan Frakes<br>Tel: +1.206-355-0230<br><br></div><br>

--089e011609cc4f078605073cfb06--


From nobody Thu Nov  6 20:21:34 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA341ACEA4 for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 20:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLPeTQD9nKpa for <dbound@ietfa.amsl.com>; Thu,  6 Nov 2014 20:21:32 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9FC1ACE9B for <dbound@ietf.org>; Thu,  6 Nov 2014 20:21:31 -0800 (PST)
Received: (qmail 30992 invoked from network); 7 Nov 2014 04:21:30 -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=790f.545c48ca.k1411; bh=IHa1Wz2e8rxzjZYGZUq5VAA0T6TdL/XEGBpAF3ysilQ=; b=eX/hq6k4St5KQDFSMqfsbwcoZlYmj3dxk/Afe0TB/vYL+AlXNgXNzgxFvo+SDf3KH4ED4l5+qPMwrrdJLJToNz26oLiQCvDHi4SHDr17srKduPheN2Ic/R8hCex2+UTy4N/dvYwwv6wOZEKfpxHJQBPcGI0ehPO3t1vHsfJAe+1A6S4ZpQvsC4Jz9KsEq8oIpQnbiZzodP72r+PJqwtjXg/3uqzGYzvQGy3zoeXGgzGZwwABh5NZLQLgK2WBfxlt
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=790f.545c48ca.k1411; bh=IHa1Wz2e8rxzjZYGZUq5VAA0T6TdL/XEGBpAF3ysilQ=; b=FDt+el0oaWjXbSfvl9aYmp/WFgOkxLmDbPweowbPPlpubEK8Rx6z9I+Ya7lX5+EdRwBpux6ZisitNeKQYrsT8DbXxqc9NlZ/JYM6zdnTUnEwQ2FBKWB48QRq319CKIplSnzNuAAAFi0cn6tN1/VRl73p3QL4DMyiiMpLqWLwMFDWMHy9pfWrvWFuMJsmW+WSszm2LHCxS1m076PTp+Y+ColU/ZaFEhQ1bK4RS35mK6Fm7h7LdoP6lUVK0YyBX5nY
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; 07 Nov 2014 04:21:30 -0000
Date: 6 Nov 2014 23:21:29 -0500
Message-ID: <alpine.OSX.2.11.1411062312450.46220@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Jothan Frakes" <jothan@jothan.com>
In-Reply-To: <CAGrS0FK+JE2nnniq9Ax=X4DGEpgDD1_mz_VxWmb-8PX1Oc1xVQ@mail.gmail.com>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan> <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com> <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com> <CAGrS0FK+JE2nnniq9Ax=X4DGEpgDD1_mz_VxWmb-8PX1Oc1xVQ@mail.gmail.com>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/T5gi3AG_1xdr74m6FDHnbPuHbpM
Cc: dbound@ietf.org
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 04:21:33 -0000

> I do think that by leaving this aspect of the dialog undefined or loosely
> defined, and working without a foundation, efforts to create any standards
> may be challenging.

Dunno if you've seen the notes, but the effort so far has primarily been 
focused on identifying the various applications for which people use the 
Mozilla PSL or something like it.  Then we can look at what semantics the 
applications need, how that does or doesn't match the various technical 
proposed approches, and we might be able to come up with a small set 
(ideally one, but don't count on it) that is broadly enough useful to be 
worth standardizing and implementing.

It's become clear that once you get much beyond "here is a TLD-like cut 
point" the semantics get rather difficult. For example, for some 
applications you want what I've called opt-in, assume two names are under 
different management unless you have a reason to believe they're the same, 
while for others you want opt-out, everything in a syntactic group of 
names (like a subtree) are under the same management unless you have a 
reason to believe they're different.  Then layer on top of that questions 
about whether people can make credible assertions on their own behalf, or 
whether you want to hear them from a third party (what the PSL is), what 
kind of distribution (batch download like the PSL or individual queries 
like the DNS?) and it gets messy fast.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Fri Nov  7 08:01:16 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B2B1A8837 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 08:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27f_w3-U3K1V for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 08:01:10 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66BF1A882C for <dbound@ietf.org>; Fri,  7 Nov 2014 08:01:10 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 7 Nov 2014 08:01:07 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 7 Nov 2014 08:01:08 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Status?
Thread-Index: AQHPve8FfuYYu/ZLKEa5IjVIJk3X4pvdDVcAgAD3UgCAAAWQAIAAC3QAgHNme4CAAAMbAIAEDEeAgAADToCAAG+lAA==
Date: Fri, 7 Nov 2014 16:01:08 +0000
Message-ID: <D08255B9.6A92%edward.lewis@icann.org>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan> <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com> <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com> <CAGrS0FK+JE2nnniq9Ax=X4DGEpgDD1_mz_VxWmb-8PX1Oc1xVQ@mail.gmail.com> <alpine.OSX.2.11.1411062312450.46220@ary.lan>
In-Reply-To: <alpine.OSX.2.11.1411062312450.46220@ary.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [192.0.44.1]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498202864_184557"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/W4eGNpV5UhcTJGTEamz8qifi9jA
Cc: Edward Lewis <edward.lewis@icann.org>
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 16:01:14 -0000

--B_3498202864_184557
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

On 11/6/14, 23:21, "John R Levine" <johnl@taugh.com> wrote:

>Dunno if you've seen the notes, but the effort so far has primarily been
>focused on identifying the various applications for which people use the
>Mozilla PSL or something like it.

Perhaps in there is a stumbling point.

We could attack this by looking at various applications that compare
properties of identifiers (one level up in abstraction over names).

We could attack this by looking at the way names are managed as domain
names, from DNS to PSL.

Combing the work to be applications=8Aus[ing]=8APSL might be warping the
problem statement.  Whether by pulling in talk about the DNS and PSL
mechanics too soon or by inappropriately drawing a line around the use
cases needing a solution.

(Mostly a reaction to the =B3the=B2 in =B3the effort=B2 - as opposed to saying
that =B3an effort so far=8A=B2)

Just throwing this out there.

--B_3498202864_184557
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQeUWyn5Efb1+JXZNxb
WafOIAeKmjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDcxNjAxMDRaMA0GCSqGSIb3DQEBAQUABIIBAJJeU1uOtiJDqEmROHNpBTeY+xWpdLshZYqS
99UHzZtnibV/IdyJ/chOL2qikd4g3K11xetGZwWP2AYTbGHFO6SoYjhVbDuqSowHwLPSur+t
zMEraMz+fp+WXIf+BV5o3KsXaulLazWi9M2G1N/4u0dLGLTjmKrp3+8jC4gcgc2OFl9VUIgK
/3q2NjBxLIw7FuVq43DsGohGwQSPQn/lEH6jFj+84C1X099agogtQggo4MLA77RMIi37b5bx
IcDXu4PK7rDWfz/yh2HCOl+00VfWDWTCYrDNNHsEs4J18YeZHtCyQRhFWJNPtFvHyQN77yNr
Zc4bS8ZbCpI4Mh9ekCM=

--B_3498202864_184557--


From nobody Fri Nov  7 08:59:28 2014
Return-Path: <suzworldwide@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06B41AD38D for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 08:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azt69Yj56lOn for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 08:59:15 -0800 (PST)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262F71AD387 for <dbound@ietf.org>; Fri,  7 Nov 2014 08:59:15 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id fa1so3878109pad.11 for <dbound@ietf.org>; Fri, 07 Nov 2014 08:59:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bjW0f3HMqCGHIpoiaXOsVGUJCs+YKIIzVyFOI3YBvrk=; b=sZgeEjzNDkqfMgRTJGYDKLln7CYFCuYnAKGzfXsWX1mksUq6Yb/Y6Yo9Ek+ab/Kj0V 3QdtQ0ngDwvQL+AhDB0GjQxZXVk/Eb8V3RkR2Kt6sU7QGutPslI+GNdZfuhNKfWghRig 0Ts9lcZQBco2LSU2faxu5YX2DooiCXR7TauudLGocm0zPosuL9RV7zjFo3FQtE+u36aQ Naet4ueG1cQTSCA8joMSwguGBXvjcuZoa5BbSmy60+XXzxchMERaqS77znfX4xzrRimr eWsYVgSwBJnyHXp/eqnn17Y4vevlNiGE6BYzjg5r/ouX+iE8b8h6ineDsZFu0li8qZLn LjXw==
X-Received: by 10.70.56.103 with SMTP id z7mr4014618pdp.164.1415379554339; Fri, 07 Nov 2014 08:59:14 -0800 (PST)
Received: from [10.11.45.146] (rrcs-173-197-107-9.west.biz.rr.com. [173.197.107.9]) by mx.google.com with ESMTPSA id rh5sm9304835pdb.4.2014.11.07.08.59.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 08:59:13 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20141105214707.1557.qmail@ary.lan>
Date: Fri, 7 Nov 2014 11:59:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
References: <20141105214707.1557.qmail@ary.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/5LH6B2cBFKuX4m3ax31uZXLhfGA
Cc: noloader@gmail.com, dbound@ietf.org
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 16:59:25 -0000

On Nov 5, 2014, at 4:47 PM, John Levine <johnl@taugh.com> wrote:

>> I'm not sure why the IETF feels its OK to issue a certificate for
>> *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
>> seen any reasoning.
>=20
> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
> *.neustar or *.williamhill if the TLD registrants (who are the same as
> the registries) ask for them?
>=20
> R's,
> John
>=20
> PS: Those are real TLDs, and I have the zone files to prove it.

I had the same question John did. Isn't the question for the CA whether =
to issue a cert to the proper authority for the domain? TLDs have those =
just like domains further down the tree do.

This actually further confuses me about why the cc/g distinction is =
important in this context.

The cc/g distinction is about domain policy, but it's about where the =
policy authority comes from, not what it does. If I can register =
whatever I want there ("public"), how does it help to know whether the =
policy I'm relying on comes from an operator under a contract with =
ICANN?

The "vanity" TLDs, and the entire new menagerie of registry =
administrative attributes relevant to policy, ("closed," "new g/old g," =
"idn cc," etc.) seem to provide endless opportunity for fairly arbitrary =
policy about delegations. Public/private seems to be a proxy for that, =
allowing perhaps easy recognition of two of the most common sets of =
rules, but I suspect it's going to get less helpful as time goes by.

I do realize I must be missing something, as I know a lot about DNS, a =
lot about TLD policy, and a lot less about what's in between.

thanks,
Suzanne


From nobody Fri Nov  7 09:40:01 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B0F1AD3C5 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNWE6aJgR7vN for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:39:54 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087FF1AD3C3 for <dbound@ietf.org>; Fri,  7 Nov 2014 09:39:53 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id rp18so5644775iec.12 for <dbound@ietf.org>; Fri, 07 Nov 2014 09:39:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W5yTwFyxvOBwF6ab9mpdkCH/cQfgPQCxjMRaCynMWhQ=; b=LRmV1klr8j/0P2qRnKZNh1+Qk6btWRZne48S7VgU4VDwKbe/4BlC9vqHGlYugUR9/E y82HhXTMgkoSxE4UvNo1wdONGJ6VUyoZMNiDfW0ve/JqICgndgro77I392anDcIe+J65 mhQ3eKYyepWjHT+k0FmMQqr80+4stu8QDcJFo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W5yTwFyxvOBwF6ab9mpdkCH/cQfgPQCxjMRaCynMWhQ=; b=XbfwxRKonVu6JhAAlihGLPP9oXTIBb7h9WTCznFMNl1e1+mgxzuBnqa9PXrjNuNKlt OzYgyug407AP/XsQSl7xFLHR17SsGI/lw1u5ZlehgPQkJOJRnvJkRpEQLw0U1zzn6SB1 4z5+adsHN2iiuXr1uC7bJsDR23X1Pdj0Q5sezlfJQrTzkBSWWoiNkeUIIyaVU9Hwygb7 ACLqaGcLTglapxO2DzAEDjOCBvFJy2EI1ZJibwfFKUR+6gLSpRlRjeLKmsAR0P2gqQJ5 kXTS/hI+VxYtAMpPWK+GcSHoBW2q8RepdkzSpAg4IDAaGAHsmbFdsFt4V9/9p89dsD8n W1OQ==
X-Gm-Message-State: ALoCoQk6GLh4wbgmUl24bW5qn0BhgCMnafNAGhVwE05pRbaZOpR4RQPCBYRtJ8L61o0kpQljS503
MIME-Version: 1.0
X-Received: by 10.50.43.135 with SMTP id w7mr5651518igl.0.1415381993090; Fri, 07 Nov 2014 09:39:53 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Fri, 7 Nov 2014 09:39:52 -0800 (PST)
In-Reply-To: <alpine.OSX.2.11.1411062312450.46220@ary.lan>
References: <CAEKtLiS6hQqF5D-MTscKBP3=4FPm_6O6vumZmA8xsUoABdyzZg@mail.gmail.com> <20140823035200.25006.qmail@joyce.lan> <CAH8yC8msQfk_y2N17XLx_HRWX6GiCjx4ByeAZJBAA1=XEoDffA@mail.gmail.com> <alpine.BSF.2.11.1408230043490.25137@joyce.lan> <0E06C3CA-F1D6-4A08-B8A3-214C1C6B6931@gmail.com> <CAEKtLiSL42WJ928Jjt73Qi5fFxibHxYDpMR0eG0qpFuTk4+EUg@mail.gmail.com> <CAGrS0FK+JE2nnniq9Ax=X4DGEpgDD1_mz_VxWmb-8PX1Oc1xVQ@mail.gmail.com> <alpine.OSX.2.11.1411062312450.46220@ary.lan>
Date: Fri, 7 Nov 2014 12:39:52 -0500
Message-ID: <CAEKtLiQ++hXMqsvsfGCPKbGSfc-96dLWQnC5VQao6d0fQ01QUg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=089e01228114eb8c400507484c99
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/YY6uswQma2dxbqGOHa2UZSciVuU
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 17:39:58 -0000

--089e01228114eb8c400507484c99
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 6, 2014 at 11:21 PM, John R Levine <johnl@taugh.com> wrote:

> I do think that by leaving this aspect of the dialog undefined or loosely
>> defined, and working without a foundation, efforts to create any standards
>> may be challenging.
>>
>
> Dunno if you've seen the notes, but the effort so far has primarily been
> focused on identifying the various applications for which people use the
> Mozilla PSL or something like it.


The proposed problem statement focuses on identifying the nature of domain
name relationships, including the inherent characteristics of so-called
public suffixes, whose enumeration is the core functionality provided by
the PSL.  Identifying applications is a supporting component to give proper
perspective, motivation, and demand to the problem statement.

Best regards,
Casey

--089e01228114eb8c400507484c99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Nov 6, 2014 at 11:21 PM, John R Levine <span dir=
=3D"ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@tau=
gh.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
I do think that by leaving this aspect of the dialog undefined or loosely<b=
r>
defined, and working without a foundation, efforts to create any standards<=
br>
may be challenging.<br>
</blockquote>
<br></span>
Dunno if you&#39;ve seen the notes, but the effort so far has primarily bee=
n focused on identifying the various applications for which people use the =
Mozilla PSL or something like it.</blockquote><div><br></div><div>The propo=
sed problem statement focuses on identifying the nature of domain name rela=
tionships, including the inherent characteristics of so-called public suffi=
xes, whose enumeration is the core functionality provided by the PSL.=C2=A0=
 Identifying applications is a supporting component to give proper perspect=
ive, motivation, and demand to the problem statement.<br><br></div><div>Bes=
t regards,<br>Casey<br></div></div></div></div>

--089e01228114eb8c400507484c99--


From nobody Fri Nov  7 09:46:40 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21A11A889C for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.363
X-Spam-Level: 
X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-EeGor6osvg for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:46:36 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E7E1AD3C9 for <dbound@ietf.org>; Fri,  7 Nov 2014 09:46:36 -0800 (PST)
Received: (qmail 28112 invoked from network); 7 Nov 2014 17:46:35 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Nov 2014 17:46:35 -0000
Date: 7 Nov 2014 17:46:13 -0000
Message-ID: <20141107174613.8379.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <D08255B9.6A92%edward.lewis@icann.org>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/7UMJSddWgQzxEhPZ8GRIV0pwB0Y
Cc: edward.lewis@icann.org
Subject: Re: [Dbound] Status?
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 17:46:37 -0000

>>Dunno if you've seen the notes, but the effort so far has primarily been
>>focused on identifying the various applications for which people use the
>>Mozilla PSL or something like it.
>
>Perhaps in there is a stumbling point.
>
>We could attack this by looking at various applications that compare
>properties of identifiers (one level up in abstraction over names).

The difficulty is straightforward: different applications have very
different needs. Deciding whether to issue a wildcard cert and finding
a policy record for DMARC both look for boundaries in the DNS, but the
issues are otherwise quite different.

It's hard to see how making things more abstract would help.

R's,
John



From nobody Fri Nov  7 09:53:54 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD981A887A for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZfCnCemZBER for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 09:53:49 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B78A1AD3C2 for <dbound@ietf.org>; Fri,  7 Nov 2014 09:53:48 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id n15so3125970lbi.34 for <dbound@ietf.org>; Fri, 07 Nov 2014 09:53:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V3YFO/yywuknknScbFkrbQ9FJ4fyPJGNriPfaKcjew0=; b=WPlxJ0JxZfK6XybP580kzvsI0OlyygDmkfaPkAdYG8jh8uRa3Kmdyt0BcLGXCUBS6e hKWs5ovh8d092DWeSm4fAOt05aOfCKsEDrn8yvW1Myf/GkJ+MggEz0EwJHzb9V15M6X5 gpK7aGZp4c7VUkjscL60WGQ/2DHMMKlTwqbO2zQa8C4Ba2QEkXjg+eGyxTd+BzIYGyd+ UV7G26ZZvpifGU4PbKz2oHjd1DRnX4zpv2Xpgx+yxgm1+YZD+HnG4oL6+8CZ9fKZXvRv JqbNaTc8Nxf13UvU5qWA3/S4USwrO/4CrJFnijcMpyJM8H7s7Zt4A2UgtH7LPy861fpe lzFg==
X-Gm-Message-State: ALoCoQkLPqHX7XOGpULvHDYijMN8WtZ/CSCseZ0NKtAOdlYf4qwQpQTB02mVkzLntJkTqA1C7WMW
X-Received: by 10.152.19.133 with SMTP id f5mr3786768lae.87.1415382826717; Fri, 07 Nov 2014 09:53:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.170.194 with HTTP; Fri, 7 Nov 2014 09:53:16 -0800 (PST)
In-Reply-To: <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
From: Jothan Frakes <jothan@jothan.com>
Date: Fri, 7 Nov 2014 09:53:16 -0800
Message-ID: <CAGrS0F+n-5NFXG9VtjhwEmBcy6fg26Jtrqj2bsyew81Tke7d8A@mail.gmail.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary=089e014940429baaf00507487e9f
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/klbyvffDOeF4L36cj3x_awdEc5I
Cc: "noloader@gmail.com" <noloader@gmail.com>, John Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 17:53:51 -0000

--089e014940429baaf00507487e9f
Content-Type: text/plain; charset=UTF-8

>>The cc/g distinction is about domain policy, but it's about where the
policy
>>authority comes from, not what it does. If I can register whatever I want
>>there ("public"), how does it help to know whether the policy I'm relying
>>on comes from an operator under a contract with ICANN?

The domain policy thing is a component of the problem space

Developers and Integrators:  Form validations, email, search, and other
integration use just practically care where to snap the line on what aspect
of the domain provided is part of a static group and that it is a real
extension.  These folks are looking for a rapid, reliable, and stable
mechanism for their specific validation purpose, and don't necessarily care
about public/private - just existence and how many dots are included in it
working from the right.

They are pilots who want to land a plane and don't necessarily care if it
is a Spanish, British, French, Independent  or other territory or are part
of the UN, they just care about the runway length.





Jothan Frakes
Tel: +1.206-355-0230


On Fri, Nov 7, 2014 at 8:59 AM, Suzanne Woolf <suzworldwide@gmail.com>
wrote:

>
> On Nov 5, 2014, at 4:47 PM, John Levine <johnl@taugh.com> wrote:
>
> >> I'm not sure why the IETF feels its OK to issue a certificate for
> >> *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
> >> seen any reasoning.
> >
> > There are now vanity TLDs.  Why shouldn't a CA sign a cert for
> > *.neustar or *.williamhill if the TLD registrants (who are the same as
> > the registries) ask for them?
> >
> > R's,
> > John
> >
> > PS: Those are real TLDs, and I have the zone files to prove it.
>
> I had the same question John did. Isn't the question for the CA whether to
> issue a cert to the proper authority for the domain? TLDs have those just
> like domains further down the tree do.
>
> This actually further confuses me about why the cc/g distinction is
> important in this context.
>
> The cc/g distinction is about domain policy, but it's about where the
> policy authority comes from, not what it does. If I can register whatever I
> want there ("public"), how does it help to know whether the policy I'm
> relying on comes from an operator under a contract with ICANN?
>
> The "vanity" TLDs, and the entire new menagerie of registry administrative
> attributes relevant to policy, ("closed," "new g/old g," "idn cc," etc.)
> seem to provide endless opportunity for fairly arbitrary policy about
> delegations. Public/private seems to be a proxy for that, allowing perhaps
> easy recognition of two of the most common sets of rules, but I suspect
> it's going to get less helpful as time goes by.
>
> I do realize I must be missing something, as I know a lot about DNS, a lot
> about TLD policy, and a lot less about what's in between.
>
> thanks,
> Suzanne
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>

--089e014940429baaf00507487e9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;&gt;<span style=3D"font-family:arial,sans-serif;font-s=
ize:12.8000001907349px">The cc/g distinction is about domain policy, but it=
&#39;s about where the policy=C2=A0</span><div><span style=3D"font-family:a=
rial,sans-serif;font-size:12.8000001907349px">&gt;&gt;authority comes from,=
 not what it does. If I can register whatever I want=C2=A0</span></div><div=
><span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">=
&gt;&gt;there (&quot;public&quot;), how does it help to know whether the po=
licy I&#39;m relying=C2=A0</span></div><div><span style=3D"font-family:aria=
l,sans-serif;font-size:12.8000001907349px">&gt;&gt;on comes from an operato=
r under a contract with ICANN?</span><div><span style=3D"font-family:arial,=
sans-serif;font-size:12.8000001907349px"><br></span></div></div><div><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">The dom=
ain policy thing is a component of the problem space =C2=A0=C2=A0</span></d=
iv><div><span style=3D"font-family:arial,sans-serif;font-size:12.8000001907=
349px"><br></span></div><div><span style=3D"font-family:arial,sans-serif;fo=
nt-size:12.8000001907349px">Developers and Integrators: =C2=A0Form validati=
ons, email, search, and other integration use just practically care where t=
o snap the line on what aspect of the domain provided is part of a static g=
roup and that it is a real extension.=C2=A0 These folks are looking for a r=
apid, reliable, and stable mechanism for their specific validation purpose,=
 and don&#39;t necessarily care about public/private - just existence and h=
ow many dots are included in it working from the right. =C2=A0</span></div>=
<div><span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349=
px"><br></span></div><div><font face=3D"arial, sans-serif"><span style=3D"f=
ont-size:12.8000001907349px">They are pilots who want to land a plane and d=
on&#39;t necessarily care if it is a Spanish, British, French,=C2=A0Indepen=
dent=C2=A0 or other territory or are part of the UN, they just care about t=
he runway length.</span></font></div><div><span style=3D"font-family:arial,=
sans-serif;font-size:12.8000001907349px"><br></span></div><div><span style=
=3D"font-family:arial,sans-serif;font-size:12.8000001907349px"><br></span><=
/div><div><br></div></div><div class=3D"gmail_extra"><br clear=3D"all"><div=
><div class=3D"gmail_signature"><div dir=3D"ltr"><br>Jothan Frakes<br>Tel: =
+1.206-355-0230<br><br></div></div></div>
<br><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 8:59 AM, Suzanne Wool=
f <span dir=3D"ltr">&lt;<a href=3D"mailto:suzworldwide@gmail.com" target=3D=
"_blank">suzworldwide@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D""><br>
On Nov 5, 2014, at 4:47 PM, John Levine &lt;<a href=3D"mailto:johnl@taugh.c=
om">johnl@taugh.com</a>&gt; wrote:<br>
<br>
&gt;&gt; I&#39;m not sure why the IETF feels its OK to issue a certificate =
for<br>
&gt;&gt; *.com, *.net, etc. I&#39;ve looked in RFC 5280 and 6125, and I&#39=
;ve never<br>
&gt;&gt; seen any reasoning.<br>
&gt;<br>
&gt; There are now vanity TLDs.=C2=A0 Why shouldn&#39;t a CA sign a cert fo=
r<br>
&gt; *.neustar or *.williamhill if the TLD registrants (who are the same as=
<br>
&gt; the registries) ask for them?<br>
&gt;<br>
&gt; R&#39;s,<br>
&gt; John<br>
&gt;<br>
&gt; PS: Those are real TLDs, and I have the zone files to prove it.<br>
<br>
</span>I had the same question John did. Isn&#39;t the question for the CA =
whether to issue a cert to the proper authority for the domain? TLDs have t=
hose just like domains further down the tree do.<br>
<br>
This actually further confuses me about why the cc/g distinction is importa=
nt in this context.<br>
<br>
The cc/g distinction is about domain policy, but it&#39;s about where the p=
olicy authority comes from, not what it does. If I can register whatever I =
want there (&quot;public&quot;), how does it help to know whether the polic=
y I&#39;m relying on comes from an operator under a contract with ICANN?<br=
>
<br>
The &quot;vanity&quot; TLDs, and the entire new menagerie of registry admin=
istrative attributes relevant to policy, (&quot;closed,&quot; &quot;new g/o=
ld g,&quot; &quot;idn cc,&quot; etc.) seem to provide endless opportunity f=
or fairly arbitrary policy about delegations. Public/private seems to be a =
proxy for that, allowing perhaps easy recognition of two of the most common=
 sets of rules, but I suspect it&#39;s going to get less helpful as time go=
es by.<br>
<br>
I do realize I must be missing something, as I know a lot about DNS, a lot =
about TLD policy, and a lot less about what&#39;s in between.<br>
<br>
thanks,<br>
Suzanne<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Dbound mailing list<br>
<a href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br>
</div></div></blockquote></div><br></div>

--089e014940429baaf00507487e9f--


From nobody Fri Nov  7 10:44:42 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E771AD408 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 10:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sy_v4TuHQK3 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 10:44:38 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0244F1AD414 for <dbound@ietf.org>; Fri,  7 Nov 2014 10:44:38 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id hn18so5914441igb.3 for <dbound@ietf.org>; Fri, 07 Nov 2014 10:44:37 -0800 (PST)
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-type; bh=BQjAvmGWx31OCvSptL42mupQmr24f4VL9CP4RGNpeAk=; b=bX04CYmsa8TPSIJ6KiR/UNq8OdEuJx7WeQNu76wBKbBuXDpO7R/vSv5mU0ALtnhYWo wTZc5842syzSIfu33f9dZ5wqr11qkLNF9eZk+w9rdel8gLKgz3m82Di2GCLPZlnobUxW AXRRLO13DxvUGKHYwdu3kCU9pw3bB8OW2183T3wE29mMf6+q1elU2P2rs5ADLEyzKNi7 YyIwkEnzZ1ax25z80KwKTDJdQa3mQPqXaZZ7aabz6nSvqCmBlbDa1hlP2aGZFauCjeze O2Scyn78OPAIkN+/KqDWHO7MYhRBR3LM4aOSpNiHchKvjvFeKyDC/GnaQhvu7L76+4v6 OrSw==
MIME-Version: 1.0
X-Received: by 10.107.28.131 with SMTP id c125mr14790128ioc.29.1415385877154;  Fri, 07 Nov 2014 10:44:37 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Fri, 7 Nov 2014 10:44:37 -0800 (PST)
In-Reply-To: <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
Date: Fri, 7 Nov 2014 13:44:37 -0500
Message-ID: <CAH8yC8ndTGHnLZFpSSqbv8SiAi1N5yQURMUwHTgP2d1-uAyqMA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Yyg5kW95bn2z8JbiTURrfUox9xw
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 18:44:40 -0000

Hi Suzanne,

On Fri, Nov 7, 2014 at 11:59 AM, Suzanne Woolf <suzworldwide@gmail.com> wrote:
>
> On Nov 5, 2014, at 4:47 PM, John Levine <johnl@taugh.com> wrote:
>
>>> I'm not sure why the IETF feels its OK to issue a certificate for
>>> *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
>>> seen any reasoning.
>>
>> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
>> *.neustar or *.williamhill if the TLD registrants (who are the same as
>> the registries) ask for them?
>> ...
>
> I had the same question John did. Isn't the question for the CA whether to issue a cert to the proper authority for the domain? TLDs have those just like domains further down the tree do.
>
> This actually further confuses me about why the cc/g distinction is important in this context.
If I am reading it correctly, then there is no difference between
gTLDs and ccTLDs.

For my needs, I need to know how to recognize or detect gTLDs and
ccTLDs (and the vanities, as John pointed out). I also need to know
how to recognize second level domains, like *.co.uk (as someone else
mentioned). Finally, it would be nice to know how to recognize
administrative boundaries, like between blogspot.com, foo.blogspot.com
and bar.blogspot.com.

I'm more concerned with the first two cases (gTLDs/ccTLDs and second
level domains). I'm concerned about these two cases because I have
witnessed attacks on them. A nice feature would be to avoid DNS and a
network call since each could be complicit in an attack on the TLD.
That's why I differentiate between top level/second level and the rest
of the zoo.

I'm less concerned with the administrative boundaries between, for
example, blogspot.com and foo.blogspot.com. Right now, I'm using a
PSL-like list for the administrative boundaries, but I would like
something cleaner if its available.

Finally, I need to know where to tell people to go look when their
software needs the same security controls. I can't say "You need to do
X" and not have a reference for X. I hope DBOUND will provide X so I
can say "You need to do X, and go look at DBOUND".


From nobody Fri Nov  7 10:46:17 2014
Return-Path: <rubensk@nic.br>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213701AD415 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 10:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.245
X-Spam-Level: 
X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-7ZeKaEO8ZI for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 10:46:12 -0800 (PST)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581511AD408 for <dbound@ietf.org>; Fri,  7 Nov 2014 10:46:12 -0800 (PST)
Received: from [10.0.12.243] (unknown [201.229.97.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 209732080512; Fri,  7 Nov 2014 16:46:08 -0200 (BRST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E6B9C61-83CF-4980-BD8B-75BFB4C2956F"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Rubens Kuhl <rubensk@nic.br>
In-Reply-To: <CAGrS0F+n-5NFXG9VtjhwEmBcy6fg26Jtrqj2bsyew81Tke7d8A@mail.gmail.com>
Date: Fri, 7 Nov 2014 14:46:06 -0400
Message-Id: <2C376645-F0E0-486B-96D5-A8DCDF9770A0@nic.br>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <CAGrS0F+n-5NFXG9VtjhwEmBcy6fg26Jtrqj2bsyew81Tke7d8A@mail.gmail.com>
To: Jothan Frakes <jothan@jothan.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/mBzNj-gfj8IUn5oSKNx1n4_YBaw
Cc: "noloader@gmail.com" <noloader@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, John Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 18:46:15 -0000

--Apple-Mail=_3E6B9C61-83CF-4980-BD8B-75BFB4C2956F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


When one looks at maps and charts, some boundaries are different from =
others. So if the information source has a clear difference for those, =
for instance what has a match in RDAP delegation and what has not, it =
would be up for those who use the information to make a decision based =
on it.=20

In your exemple, sometimes only the runway length matters, like landing =
a plane in an SOS situation. Sometimes the sovereignty lines matter, =
like a plane carrying a political refugee.=20


Rubens

> On Nov 7, 2014, at 1:53 PM, Jothan Frakes <jothan@jothan.com> wrote:
>=20
> >>The cc/g distinction is about domain policy, but it's about where =
the policy=20
> >>authority comes from, not what it does. If I can register whatever I =
want=20
> >>there ("public"), how does it help to know whether the policy I'm =
relying=20
> >>on comes from an operator under a contract with ICANN?
>=20
> The domain policy thing is a component of the problem space  =20
>=20
> Developers and Integrators:  Form validations, email, search, and =
other integration use just practically care where to snap the line on =
what aspect of the domain provided is part of a static group and that it =
is a real extension.  These folks are looking for a rapid, reliable, and =
stable mechanism for their specific validation purpose, and don't =
necessarily care about public/private - just existence and how many dots =
are included in it working from the right.=20
>=20
> They are pilots who want to land a plane and don't necessarily care if =
it is a Spanish, British, French, Independent  or other territory or are =
part of the UN, they just care about the runway length.
>=20
>=20
>=20
>=20
>=20
> Jothan Frakes
> Tel: +1.206-355-0230
>=20
>=20
> On Fri, Nov 7, 2014 at 8:59 AM, Suzanne Woolf <suzworldwide@gmail.com =
<mailto:suzworldwide@gmail.com>> wrote:
>=20
> On Nov 5, 2014, at 4:47 PM, John Levine <johnl@taugh.com =
<mailto:johnl@taugh.com>> wrote:
>=20
> >> I'm not sure why the IETF feels its OK to issue a certificate for
> >> *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
> >> seen any reasoning.
> >
> > There are now vanity TLDs.  Why shouldn't a CA sign a cert for
> > *.neustar or *.williamhill if the TLD registrants (who are the same =
as
> > the registries) ask for them?
> >
> > R's,
> > John
> >
> > PS: Those are real TLDs, and I have the zone files to prove it.
>=20
> I had the same question John did. Isn't the question for the CA =
whether to issue a cert to the proper authority for the domain? TLDs =
have those just like domains further down the tree do.
>=20
> This actually further confuses me about why the cc/g distinction is =
important in this context.
>=20
> The cc/g distinction is about domain policy, but it's about where the =
policy authority comes from, not what it does. If I can register =
whatever I want there ("public"), how does it help to know whether the =
policy I'm relying on comes from an operator under a contract with =
ICANN?
>=20
> The "vanity" TLDs, and the entire new menagerie of registry =
administrative attributes relevant to policy, ("closed," "new g/old g," =
"idn cc," etc.) seem to provide endless opportunity for fairly arbitrary =
policy about delegations. Public/private seems to be a proxy for that, =
allowing perhaps easy recognition of two of the most common sets of =
rules, but I suspect it's going to get less helpful as time goes by.
>=20
> I do realize I must be missing something, as I know a lot about DNS, a =
lot about TLD policy, and a lot less about what's in between.
>=20
> thanks,
> Suzanne
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org <mailto:Dbound@ietf.org>
> https://www.ietf.org/mailman/listinfo/dbound =
<https://www.ietf.org/mailman/listinfo/dbound>
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


--Apple-Mail=_3E6B9C61-83CF-4980-BD8B-75BFB4C2956F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><br class=3D""></div>When one looks at maps =
and charts, some boundaries are different from others. So if the =
information source has a clear difference for those, for instance what =
has a match in RDAP delegation and what has not, it would be up for =
those who use the information to make a decision based on it.&nbsp;<div =
class=3D""><br class=3D""></div><div class=3D"">In your exemple, =
sometimes only the runway length matters, like landing a plane in an SOS =
situation. Sometimes the sovereignty lines matter, like a plane carrying =
a political refugee.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">Rubens</div><div =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Nov 7, 2014, at 1:53 PM, Jothan Frakes &lt;<a =
href=3D"mailto:jothan@jothan.com" class=3D"">jothan@jothan.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">&gt;&gt;<span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">The cc/g distinction is about domain policy, but it's about =
where the policy&nbsp;</span><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">&gt;&gt;authority comes from, not what it does. If I can =
register whatever I want&nbsp;</span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">&gt;&gt;there ("public"), how does it help to know whether =
the policy I'm relying&nbsp;</span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">&gt;&gt;on comes from an operator under a contract with =
ICANN?</span><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D""><br class=3D""></span></div></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">The domain policy thing is a component of the problem space =
&nbsp;&nbsp;</span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D""><br class=3D""></span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D"">Developers and Integrators: &nbsp;Form validations, email, =
search, and other integration use just practically care where to snap =
the line on what aspect of the domain provided is part of a static group =
and that it is a real extension.&nbsp; These folks are looking for a =
rapid, reliable, and stable mechanism for their specific validation =
purpose, and don't necessarily care about public/private - just =
existence and how many dots are included in it working from the right. =
&nbsp;</span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D""><br class=3D""></span></div><div class=3D""><font =
face=3D"arial, sans-serif" class=3D""><span =
style=3D"font-size:12.8000001907349px" class=3D"">They are pilots who =
want to land a plane and don't necessarily care if it is a Spanish, =
British, French,&nbsp;Independent&nbsp; or other territory or are part =
of the UN, they just care about the runway =
length.</span></font></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D""><br class=3D""></span></div><div class=3D""><span =
style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px" =
class=3D""><br class=3D""></span></div><div class=3D""><br =
class=3D""></div></div><div class=3D"gmail_extra"><br clear=3D"all" =
class=3D""><div class=3D""><div class=3D"gmail_signature"><div dir=3D"ltr"=
 class=3D""><br class=3D"">Jothan Frakes<br class=3D"">Tel: =
+1.206-355-0230<br class=3D""><br class=3D""></div></div></div>
<br class=3D""><div class=3D"gmail_quote">On Fri, Nov 7, 2014 at 8:59 =
AM, Suzanne Woolf <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:suzworldwide@gmail.com" target=3D"_blank" =
class=3D"">suzworldwide@gmail.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br =
class=3D"">
On Nov 5, 2014, at 4:47 PM, John Levine &lt;<a =
href=3D"mailto:johnl@taugh.com" class=3D"">johnl@taugh.com</a>&gt; =
wrote:<br class=3D"">
<br class=3D"">
&gt;&gt; I'm not sure why the IETF feels its OK to issue a certificate =
for<br class=3D"">
&gt;&gt; *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've =
never<br class=3D"">
&gt;&gt; seen any reasoning.<br class=3D"">
&gt;<br class=3D"">
&gt; There are now vanity TLDs.&nbsp; Why shouldn't a CA sign a cert =
for<br class=3D"">
&gt; *.neustar or *.williamhill if the TLD registrants (who are the same =
as<br class=3D"">
&gt; the registries) ask for them?<br class=3D"">
&gt;<br class=3D"">
&gt; R's,<br class=3D"">
&gt; John<br class=3D"">
&gt;<br class=3D"">
&gt; PS: Those are real TLDs, and I have the zone files to prove it.<br =
class=3D"">
<br class=3D"">
</span>I had the same question John did. Isn't the question for the CA =
whether to issue a cert to the proper authority for the domain? TLDs =
have those just like domains further down the tree do.<br class=3D"">
<br class=3D"">
This actually further confuses me about why the cc/g distinction is =
important in this context.<br class=3D"">
<br class=3D"">
The cc/g distinction is about domain policy, but it's about where the =
policy authority comes from, not what it does. If I can register =
whatever I want there ("public"), how does it help to know whether the =
policy I'm relying on comes from an operator under a contract with =
ICANN?<br class=3D"">
<br class=3D"">
The "vanity" TLDs, and the entire new menagerie of registry =
administrative attributes relevant to policy, ("closed," "new g/old g," =
"idn cc," etc.) seem to provide endless opportunity for fairly arbitrary =
policy about delegations. Public/private seems to be a proxy for that, =
allowing perhaps easy recognition of two of the most common sets of =
rules, but I suspect it's going to get less helpful as time goes by.<br =
class=3D"">
<br class=3D"">
I do realize I must be missing something, as I know a lot about DNS, a =
lot about TLD policy, and a lot less about what's in between.<br =
class=3D"">
<br class=3D"">
thanks,<br class=3D"">
Suzanne<br class=3D"">
<div class=3D"HOEnZb"><div class=3D"h5"><br class=3D"">
_______________________________________________<br class=3D"">
Dbound mailing list<br class=3D"">
<a href=3D"mailto:Dbound@ietf.org" class=3D"">Dbound@ietf.org</a><br =
class=3D"">
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank"=
 class=3D"">https://www.ietf.org/mailman/listinfo/dbound</a><br =
class=3D"">
</div></div></blockquote></div><br class=3D""></div>
_______________________________________________<br class=3D"">Dbound =
mailing list<br class=3D""><a href=3D"mailto:Dbound@ietf.org" =
class=3D"">Dbound@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/dbound<br =
class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_3E6B9C61-83CF-4980-BD8B-75BFB4C2956F--


From nobody Fri Nov  7 11:10:47 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D961A00EA for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTAfJFKHMXuZ for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:10:42 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD3A1A012D for <dbound@ietf.org>; Fri,  7 Nov 2014 11:10:41 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 7 Nov 2014 11:10:39 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 7 Nov 2014 11:10:39 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "suzworldwide@gmail.com" <suzworldwide@gmail.com>, John Levine <johnl@taugh.com>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAV+8AgAAW9ICAAA6jAIAABrcAgAABIwCAADwDAIAADtyAgALUNgD//9DnAA==
Date: Fri, 7 Nov 2014 19:10:38 +0000
Message-ID: <D0828334.6AB9%edward.lewis@icann.org>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
In-Reply-To: <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [192.0.44.1]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498214236_499273"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/z1Ulv7FE1yM_GRpSxV8uGolJ2Xw
Cc: "noloader@gmail.com" <noloader@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 19:10:44 -0000

--B_3498214236_499273
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>On 11/7/14, 11:59, "Suzanne Woolf" <suzworldwide@gmail.com> wrote:
>
>>The cc/g distinction is about domain policy, but it's about where the
>>policy authority comes from, not what it does. If I can register
>>whatever I want there ("public"), how does it help to know whether the
>>policy I'm relying on comes from an operator under a contract with ICANN?
>
>It might, in some applications.  I have heard some expectations that the
>=B3policy=B2 of a TLD would impact how it is treated in end-user
>applications.  I don=B9t have rock-solid examples to give, but I wouldn=B9t
>rule this use case out just yet.  Yes, this might be a =B3I want a pony=B2
>but I don=B9t want to close the door on it.
>
>>The "vanity" TLDs, and the entire new menagerie of registry
>>administrative attributes relevant to policy, ("closed," "new g/old g,"
>>"idn cc," etc.) seem to provide endless opportunity for fairly arbitrary
>>policy about delegations. Public/private seems to be a proxy for that,
>>allowing perhaps easy recognition of two of the most common sets of
>>rules, but I suspect it's going to get less helpful as time goes by.
>
>The IETF shouldn=B9t worry itself about policy because the expertise is not
>available.  But the IETF shouldn=B9t burn in what it thinks of policy
>either.
>
>>I do realize I must be missing something, as I know a lot about DNS, a
>>lot about TLD policy, and a lot less about what's in between.
>
>Innovation comes in many forms - it might be related in how TLDs are run.
> It would be grand if the result of what here avoids stifling such
>innovation.  Yes, =B3I want a pony."

--B_3498214236_499273
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRva0fk1hlN7B99bmEc
3rl8fdT0xjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MDcxOTEwMzZaMA0GCSqGSIb3DQEBAQUABIIBAKmi4PUd61LqNmQ6GruvAIRPxhN9SajjYGI0
56ihurvSVsr72XPtIj/KFktwRs/q8JoHX9jkFZRPIp+CSbZ4wojhj3BppjSXK6f56Wzpzgep
CEXkI3Cyt6tEFl/q1ykRfNIdPHYglaYm9RCBmzsHyqK848H8zcqYHbsEvGKplM/mK0PDC6fb
ULMRZ5aWXT6oDXMkArG0Am3Xf3SQRp/p85Bas7ZupwvV4KltbWjHekwyncg6t6kBVAxF6FGH
9L5DXHuUnFV8DQMU9KYL5XI8jlbOG0wuZuG9bkVYNahFGcbWvL3Fdjc8AsYdgm9y4D73WzyW
8TPSJeEyI8g/fuAU6e4=

--B_3498214236_499273--


From nobody Fri Nov  7 11:32:31 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F431A037B for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:32:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u40EHxmKZKI for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:32:29 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD811A0077 for <dbound@ietf.org>; Fri,  7 Nov 2014 11:32:28 -0800 (PST)
Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B08938A035 for <dbound@ietf.org>; Fri,  7 Nov 2014 19:32:26 +0000 (UTC)
Date: Fri, 7 Nov 2014 14:32:25 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141107193224.GD36019@mx1.yitter.info>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <CAH8yC8ndTGHnLZFpSSqbv8SiAi1N5yQURMUwHTgP2d1-uAyqMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH8yC8ndTGHnLZFpSSqbv8SiAi1N5yQURMUwHTgP2d1-uAyqMA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/H5yinL8WW8YCrIZDxBPdEUlCYaA
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 19:32:29 -0000

On Fri, Nov 07, 2014 at 01:44:37PM -0500, Jeffrey Walton wrote:
> level domains). I'm concerned about these two cases because I have
> witnessed attacks on them. 

That sounds to me like arguing that you're going to put a lock on your
back door because that's where the burglars came in last time, and
neglecting to put one on the front.  I have pretty good reason to
believe that dyndns.org has more policy boundaries within it than many
ccTLDs do.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Fri Nov  7 11:35:13 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ABD1A03A9 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.559
X-Spam-Level: **
X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1BjeBVBNqRI for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:35:11 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577451A03A8 for <dbound@ietf.org>; Fri,  7 Nov 2014 11:35:11 -0800 (PST)
Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7E85C8A035 for <dbound@ietf.org>; Fri,  7 Nov 2014 19:35:10 +0000 (UTC)
Date: Fri, 7 Nov 2014 14:35:08 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141107193508.GE36019@mx1.yitter.info>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <D0828334.6AB9%edward.lewis@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D0828334.6AB9%edward.lewis@icann.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/rCQc1VrMr9QQQpwEaF-v9pgifPU
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 19:35:12 -0000

On Fri, Nov 07, 2014 at 07:10:38PM +0000, Edward Lewis wrote:
> >It might, in some applications.  I have heard some expectations that the
> >³policy² of a TLD would impact how it is treated in end-user
> >applications.  I donÂąt have rock-solid examples to give, but I wouldnÂąt
> >rule this use case out just yet.  Yes, this might be a ³I want a pony²
> >but I donÂąt want to close the door on it.

This is _exactly the same_ confusion as the one that led to the
original crumbly cookies problem.  Indeed, not only have I heard those
expectations; but when I told the relevant ministry people that zones
underneath them did not in fact inherit the policy rules from the
parent, they were shocked.  They said that ICANN should create a
policy.  I pointed out that what they were really saying was that
every computer in the known universe had to be upgraded for this to
take effect.  Even telco regulators understand field service problems.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Fri Nov  7 11:56:03 2014
Return-Path: <suzworldwide@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6C1A1A14 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWs_M0vbfwrJ for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 11:55:58 -0800 (PST)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E421E1A1A22 for <dbound@ietf.org>; Fri,  7 Nov 2014 11:55:57 -0800 (PST)
Received: by mail-pd0-f179.google.com with SMTP id g10so3866678pdj.24 for <dbound@ietf.org>; Fri, 07 Nov 2014 11:55:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eq3SGcO2x6kTLpmeuFXnmS6gJHHQ8OIaNUsPVhHtLgU=; b=GJ7Y10bI95BlBHMqvvcDdaQRGZkzu0QkWt0q4zr+NNpWcxLqt1vHan+rf1i1mZwSMk nFEPi1fcVVjC+tIRnyctBxchJqr6saTHpnyEznfE1J/vOUHIXa7WzvGaTh2Z4KCnK572 GM/HhTCoiRbZHYvXWGI2FUw9NBENsZu6PsTBRJaiYlTs3WURTkfD4S2MML9Hnxh/kVut dh46IMdvVGekKgYyMqo/rys8f1/+V8ogJ/eijebg9nxBL1EofY9w0WW43ngP5kWA6PWG HT1AIx8SEzoBtaCbPrI3WRGX9Ya7PxZMEQ8mCsLzu4FHkuKbuRnP/iVMECdpVRK7aiF8 VFvA==
X-Received: by 10.68.167.99 with SMTP id zn3mr14609985pbb.30.1415390157114; Fri, 07 Nov 2014 11:55:57 -0800 (PST)
Received: from [10.11.45.146] (rrcs-173-197-107-9.west.biz.rr.com. [173.197.107.9]) by mx.google.com with ESMTPSA id qu6sm9441672pbc.92.2014.11.07.11.55.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 11:55:56 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <D0828334.6AB9%edward.lewis@icann.org>
Date: Fri, 7 Nov 2014 14:55:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8116DCC-C676-4588-9E55-8D8FF80F3DED@gmail.com>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <D0828334.6AB9%edward.lewis@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/3dMi0HExwcnhvZGBo1bkLqgl-ZY
Cc: dbound@ietf.org
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 19:56:02 -0000

On Nov 7, 2014, at 2:10 PM, Edward Lewis <edward.lewis@icann.org> wrote:

>> On 11/7/14, 11:59, "Suzanne Woolf" <suzworldwide@gmail.com> wrote:
>>=20
>>> The cc/g distinction is about domain policy, but it's about where =
the
>>> policy authority comes from, not what it does. If I can register
>>> whatever I want there ("public"), how does it help to know whether =
the
>>> policy I'm relying on comes from an operator under a contract with =
ICANN?
>>=20
>> It might, in some applications.  I have heard some expectations that =
the
>> =B3policy=B2 of a TLD would impact how it is treated in end-user
>> applications.  I don=B9t have rock-solid examples to give, but I =
wouldn=B9t
>> rule this use case out just yet.  Yes, this might be a =B3I want a =
pony=B2
>> but I don=B9t want to close the door on it.

Right, and I'm fine with that, except that the actual distinction =
between g/cc tells you nothing at all about how a TLD, or its =
subdomains, are or should be "treated by end-user applications." It =
can't, modulo the very, very broad outlines provided by the attribute of =
a TLD that it's operated under a specific contract to ICANN. All you =
know about a cc is that it meets a specific syntactical rule ("this =
two-ascii-letter string appears in a specific lookup table") and =
*doesn't* have that "under a specific contract to ICANN" attribute.

The answers to my question have been pretty helpful in clarifying some =
distinctions I need to understand better, thanks.

>>> The "vanity" TLDs, and the entire new menagerie of registry
>>> administrative attributes relevant to policy, ("closed," "new g/old =
g,"
>>> "idn cc," etc.) seem to provide endless opportunity for fairly =
arbitrary
>>> policy about delegations. Public/private seems to be a proxy for =
that,
>>> allowing perhaps easy recognition of two of the most common sets of
>>> rules, but I suspect it's going to get less helpful as time goes by.
>>=20
>> The IETF shouldn=B9t worry itself about policy because the expertise =
is not
>> available.  But the IETF shouldn=B9t burn in what it thinks of policy
>> either.

The IETF should make technical standards that allow people who do have =
relevant policy expertise (and operational need!) to encode the policies =
they want. That does mean having a certain level of understanding of =
what policy distinctions matter to the people who have to use those =
standards. Hence my question.

(Before we get any further into this, there are at least three meanings =
of the word "policy" already conflated in this thread. I spend a lot of =
time in that maze of ratholes all alike, and one of the things I think =
it's critical to do here is avoid it as much as possible. Clarity of =
terminology will help a lot.)


thanks,
Suzanne


From nobody Fri Nov  7 12:28:45 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748D41A1AE4 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 12:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqufiun1j3ao for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 12:28:42 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11171A1AE5 for <dbound@ietf.org>; Fri,  7 Nov 2014 12:28:41 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id h3so6062572igd.13 for <dbound@ietf.org>; Fri, 07 Nov 2014 12:28:41 -0800 (PST)
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-type; bh=+kfOL1+vOrsNGgx7s5eNtm35BBkT3b0phs9Om0vGTSo=; b=G7w+8+6KFAI9X4tA3oV020levw+S7CYXH8CYiV7SsOudrQKDBQhs3vbE44wBseVcFM uziLmE+9QZYWJFzDcTpdjMp2fSqSIdH+p3fvrk8dWmwJLCz42O2huIB6GOpB+OqKKSlS 5bOSwJAR4HCDDyOdey+x6tP4JNpfJpVblnE74BCLRIhEYuvhYWgaEdsuiYDBXP8FDL4k T/ENnQY7+DfBfUt/9UJZsIDtAdROM6ef8baf+uZF9iusf2u4UD+hwbg/VmFNfR3V+W9t 8AVYofeDH7A5IH7gZV9/fJipvAJkCp/Qq3/68nAObPsK6fKPV3j6TrLLBUcuTfoAIesG C6ew==
MIME-Version: 1.0
X-Received: by 10.50.142.71 with SMTP id ru7mr6757828igb.32.1415392121002; Fri, 07 Nov 2014 12:28:41 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Fri, 7 Nov 2014 12:28:40 -0800 (PST)
In-Reply-To: <20141107193224.GD36019@mx1.yitter.info>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <CAH8yC8ndTGHnLZFpSSqbv8SiAi1N5yQURMUwHTgP2d1-uAyqMA@mail.gmail.com> <20141107193224.GD36019@mx1.yitter.info>
Date: Fri, 7 Nov 2014 15:28:40 -0500
Message-ID: <CAH8yC8mVMYwh5UOyA+2U3R2oZm+0giF9BzMX9Lwp9etVo34TpA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/prpQdy5wn-omWWeFFoLAaAcjXpY
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 20:28:43 -0000

On Fri, Nov 7, 2014 at 2:32 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> On Fri, Nov 07, 2014 at 01:44:37PM -0500, Jeffrey Walton wrote:
>> level domains). I'm concerned about these two cases because I have
>> witnessed attacks on them.
>
> That sounds to me like arguing that you're going to put a lock on your
> back door because that's where the burglars came in last time, and
> neglecting to put one on the front.  I have pretty good reason to
> believe that dyndns.org has more policy boundaries within it than many
> ccTLDs do.
>
Perhaps, but I need to solve problems I have seen in real life.

Jeff


From nobody Fri Nov  7 15:41:40 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12091A00F2 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 15:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKHDxo7uhEh6 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 15:41:36 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096691A0049 for <dbound@ietf.org>; Fri,  7 Nov 2014 15:41:35 -0800 (PST)
Received: (qmail 79489 invoked from network); 7 Nov 2014 23:41:34 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Nov 2014 23:41:34 -0000
Date: 7 Nov 2014 23:41:11 -0000
Message-ID: <20141107234111.9147.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <B8116DCC-C676-4588-9E55-8D8FF80F3DED@gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/pvmp9ygcEntvgpa1cWcjhF6AaCM
Cc: suzworldwide@gmail.com
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 23:41:37 -0000

>Right, and I'm fine with that, except that the actual distinction between g/cc tells you
>nothing at all about how a TLD, or its subdomains, are or should be "treated by end-user
>applications." It can't, modulo the very, very broad outlines provided by the attribute
>of a TLD that it's operated under a specific contract to ICANN.

Even the ICANN contracted domains have an irregular surface.  The
.name TLD originally only let you register 3rd level names like
john.smith.name, but they later added 2nd level.  Even with a copy of
the zone file it can be hard to tell where the boundary is.  This
kind of financially motivated flattening is common, e.g. .pro, .us,
and most recently .uk, with the legacy names left as lumps in the
new flat namespace.

R's,
John


From nobody Fri Nov  7 20:08:44 2014
Return-Path: <suzworldwide@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784FE1A0368 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 20:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.486
X-Spam-Level: 
X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdiPw4iNoGu9 for <dbound@ietfa.amsl.com>; Fri,  7 Nov 2014 20:08:30 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3741A00B2 for <dbound@ietf.org>; Fri,  7 Nov 2014 20:08:29 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kx10so4722462pab.6 for <dbound@ietf.org>; Fri, 07 Nov 2014 20:08:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AnGMJeGKHnTaLFEJGnvcx/8WHICBH26OrjwaF17s8Zs=; b=q+0Rowb7SxNUsdBMYwVf4HTWtWUHS9Truw4nQ3CfnKxvEbaev0MgcTSjruK0BlkCqp CBiwEjL2GerHnHmIk43xx1BE0g2bzwxxDnEoMw/CjVpawA1kYy3kpRRTrZbZxHRVe11v +VK+LipmpcTfe9ClSIhbOtvKm7B56C9pVQqMej2Hev7/Zv4FcJhMPvwduX4GeQOmFDlG CnyJIhHDT1Q2nn/TZXjE0f0MDQjW8NAEeQQvjqD05wdEuTEBnWcyYt2xOFhKa1jfBFb6 3aoR6lb0DR3DCOWV5SDUdut5OFh6swv2Dy6pPSAfNfEzq6z0I6CyCEwbBxAbyaVlubkm xTdg==
X-Received: by 10.68.197.41 with SMTP id ir9mr16956579pbc.116.1415419708360; Fri, 07 Nov 2014 20:08:28 -0800 (PST)
Received: from [10.11.45.146] (rrcs-173-197-107-9.west.biz.rr.com. [173.197.107.9]) by mx.google.com with ESMTPSA id h6sm10155404pdk.38.2014.11.07.20.08.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 20:08:27 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20141107234111.9147.qmail@ary.lan>
Date: Fri, 7 Nov 2014 23:08:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9CFA088-3762-40DB-AFC0-1736E0B46617@gmail.com>
References: <20141107234111.9147.qmail@ary.lan>
To: "John Levine" <johnl@taugh.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Hkb8vjB_OHLacnyj5rcsq9CFrZo
Cc: dbound@ietf.org
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Nov 2014 04:08:35 -0000

On Nov 7, 2014, at 6:41 PM, "John Levine" <johnl@taugh.com> wrote:

>> Right, and I'm fine with that, except that the actual distinction =
between g/cc tells you
>> nothing at all about how a TLD, or its subdomains, are or should be =
"treated by end-user
>> applications." It can't, modulo the very, very broad outlines =
provided by the attribute
>> of a TLD that it's operated under a specific contract to ICANN.
>=20
> Even the ICANN contracted domains have an irregular surface.  The
> .name TLD originally only let you register 3rd level names like
> john.smith.name, but they later added 2nd level.  Even with a copy of
> the zone file it can be hard to tell where the boundary is.  This
> kind of financially motivated flattening is common, e.g. .pro, .us,
> and most recently .uk, with the legacy names left as lumps in the
> new flat namespace.


Exactly, and as someone else said in the thread (Andrew?) the pressures =
are only going to increase as the new gTLD operators get creative with =
operational and business models.=20

I don't want to get too stuck on challenging the usefulness of the =
distinction between g's and cc's, though. My question was about what =
distinctions *are* useful, and I have a better understanding of that =
now.=20


thanks,
Suzanne




From nobody Sun Nov  9 16:24:10 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CFB1A87CA for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.832
X-Spam-Level: 
X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkft_TnV0Wj for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:24:06 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id C9C611A87C8 for <dbound@ietf.org>; Sun,  9 Nov 2014 16:24:05 -0800 (PST)
Received: (qmail 24779 invoked by uid 0); 10 Nov 2014 00:24:02 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 10 Nov 2014 00:24:02 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id DcPy1p00L2UhLwi01cQ1kr; Sun, 09 Nov 2014 17:24:01 -0700
X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=A1X0JdhQAAAA:8 a=QIhr-27iAAAA:8 a=kewnc1ipAAAA:8 a=O8BSH_48AAAA:8 a=7u2kzkQ9AAAA:8 a=W0ucIhDPAAAA:8 a=m9shYIPOAAAA:8 a=hL1costlTO4jggqM2XUA:9 a=JtmV564O68BcFxcx:21 a=EIy_EPdrT0WR5rjp:21 a=QEXdDO2ut3YA:10 a=e1i35A98MB8A:10 a=4rq7TwIXcRUA:10 a=9jDjnVP-S04A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=ZzneFSbRO+dAnxVIu7n6WnoBLyD0c5kcuLItHPtieGU=;  b=grqAepfrHvaJkdtZx1FWLrnWkiGOPXVFLGA2PlIqATSuTSCs+WBhOCNxZS8qaMOn3c9ng8YJUDtLqSVzb/R4vLQVxLkrHgE76THHmBS3Dz1jlQe0Zv6mL+i9QeL2BV4y;
Received: from [24.5.2.144] (port=49510 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Xnclz-0001E9-8g for dbound@ietf.org; Sun, 09 Nov 2014 17:23:59 -0700
Message-ID: <546005C4.3080200@KingsMountain.com>
Date: Sun, 09 Nov 2014 16:24:36 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/EATAhFdPIWOjroY5LbPUA9uwHsc
Subject: [Dbound] dbound-problem_statement-v3.txt (was: Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 00:24:09 -0000

I converted problem_statement-v3 to plain txt for convenience...


Defining and Signaling Relationships Between Domains

Casey Deccio     John Levine

Abstract

Various Internet protocols and applications require some mechanism for
determining whether two Domain Name System (DNS) names are related. In
this document we formalize the types of domain name relationships,
identify protocols and applications requiring such relationships, review
current solutions, and describe the problems that need to be addressed.

1 Introduction

The use of various Internet protocols and applications has introduced
the desire and need for designated relationships between Domain Name
System (DNS) names, beyond the lineal relationship inherent in the names
themselves. While protocols, such as that used by HTTP Cookies, have
traditionally used ancestral relationships to determine allowable scope
of information sharing and authorization, there is an increasing need to
define relationships between arbitrary domains.

We begin by introducing terminology, after which we discuss known and
conceived applications for which domain relationships are desirable or
required. We then discuss the Public Suffix List, the primary solution
for domain relationships currently available. Finally, we define the
problems that need addressing in the context of prior sections.

1.1 Terminology

For consistency in language we define terms surrounding domain names.


1.1.1 Domains and Domain Names

A domain name is a sequence of dot-separated alphanumeric words, such as
www.example.com. A domain names parent is the domain name formed by
removing the leftmost label. The parent of www.example.com is
example.com. The domain of a domain name consists of the name itself and
all its descendants (children, grandchildren, and so on). The names
x.y.z.example.com and example.com are both in the example.com domain, but=

of the two, only x.y.z.example.com is in the z.example.com domain. The
name example.org is in neither domain. The root domain name (=E2=80=9C.=E2=
=80=9D) is the
ancestor of all domain names, and its children are referred to as
top-level domains (TLDs). In a structural sense, the root is the top of
a tree, which recursively branches to each child, and a domain is the
complete subtree rooted at the name of that domain.


1.1.2 Public/private Boundaries

We refer to a domain name as having a public scope if the entity that
operates it allows the creation of children names by other entities;
otherwise, its scope is considered private. Domain names having public
and private scope may simply be referred to as public and private,
respectively. For example, many TLDs, including com, are public. Both
public and private domains may have either public and private children,
resulting in public domains within private domains and vice-versa.


1.1.3 Related Domains

We say that two domains are related if they are mutually and positively
associated with one another. For example, they might by the same entity
or that there are formal business or other relationships between the two
operating entities that require a positive association. In the most
lenient case, two domains, if related, are related for all purposes.
However, it is possible that two domains are related for explicitly
defined purposes.


1.1.4 Domain Relationships

Relationships between domains are natural, expected, and already exist.
Many relationships are hierarchical, i.e., following the ancestral
structure of the DNS tree, and many are not. Two related domains need
not be in the same scope.

Intra-domain Relationships: The most natural of relationships between
domains is when one is within the other, such as a parent/child
relationship. There are two major subclasses of intra-domain
relationships: those that cross domain scope, and those that are within
the same scope. In the former case, one or more boundaries exist between
the domains. For example, assuming example.com is a private domain name
under com (which is public), there is a change in scope from public to
private between com and example.com and thus a scope boundary between
the two.

Between two related domains within the same scope, there may be
organizational boundaries. For example, if foo.example.com, with private
scope, is operated by a business office of its parent organization,
which operates example.com, there might be policy or political
constraints for which an organizational boundary exists between the two.

Cross-domain Relationships: Relationships between non-overlapping
domains is also common. For example, example.com and example.org might
be operated by the same organization, but that organization uses them
interchangeably.


2 Known Applications for Domain Relationships

2.1 HTTP Cookies

The DNS is used extensively in conjunction with the Hypertext Transfer
Protocol (HTTP). In addition to domain name resolution, the DNS is used
by HTTP clients for enforcing policy.

HTTP clients maintain local state in the form of key/value pairs known
as cookies. While most often cookies are initially set by HTTP servers,
HTTP clients send all cookies in HTTP requests for which the domain name
of the Uniform Resource Locator (URL) is within the the cookies=E2=80=99 =
scope.

The scope of a cookie is defined using a domain name in the =E2=80=9Cdoma=
in=E2=80=9D
attribute of the cookie. When a cookie=E2=80=99s =E2=80=9Cdomain=E2=80=9D=
 attribute is specified
as a domain name (as opposed to an Internet Protocol address), the
domain name in the URL is considered within scope if it is a descendent
of the =E2=80=9Cdomain=E2=80=9D attribute.

By policy, HTTP clients are not allowed to respect a cookie domain at the=

TLD level or higher. Such domains have inherent public scope, and cookies=

having such scope would enable the association of HTTP requests across
different, independently operated domains. This association raises
concerns of user privacy and security.

The TLD restriction alone is insufficient to address the privacy and
security concerns with cookies. For example, many country-code TLDs
(ccTLDs) designate public second-level domains (e.g., com.ac).
Additionally, relationships are only defined within the DNS hierarchy;
cross-domain relationships are not supported.

2.2 Email sender verification

An emerging sender verification called Domain-based Message
Authentication, Reporting and Conformance (DMARC) [1] attempts to
validate the domain name of the author=E2=80=99s address on the message=E2=
=80=99s =E2=80=9CFrom:=E2=80=9D
header using the DomainKeys Identified Email (DKIM) and Sender Policy
Framework (SPF) authentication schemes. A DKIM signature and SPF check
each validate a specific domain name. For DKIM it is the domain name
corresponding the DKIM signature. For SPF the domain name of the
message=E2=80=99s bounce address is validated. DMARC allows approximate m=
atching
between the author=E2=80=99s domain and the validated domain, where one c=
an be an
ancestor or descendant of the other.


Entry           | Meaning
-----------------------------------------------
example         | example is public
*.example       | All children of example are public
!foo.example    | foo.example is private

Table 1: Contrived PSL entries.


DMARC validators are supposed to ensure that the two domains are under
the same management, the specifics of which are deliberately left out of
the spec.


2.3 SSL certificate requests

Secure Socket Layer (SSL) certificate authorities typically validate
certificate signing requests by sending a confirmation message to one of
the WHOIS contacts for the (private scope) domain name [2]. In cases
where there are multiple levels of delegation (i.e., crossing
public/private scopes), the WHOIS contact needs to be the one for the
registrant of the domain, not a higher level registration.

When an SSL certificate is for a wildcard domain, the entire range of
names covered by the wildcard needs to be under the same control.
Authorities do not (knowingly) issue certificates for public domains
such as *.com.ac.


3 Public Suffix List

To further address HTTP security and privacy concerns surrounding cookie
  scope and use, a list of publix suffixes was developed by Mozilla
Firefox developers. This list, known as the Public Suffix List (PSL) [3],=

is maintained with the Mozilla Firefox source code and includes a more
extended list of known public suffixes, so cookie policies originally
applied only to TLDs can be applied generally to identified public
suffixes.

The PSL includes placeholder public domains designated by =E2=80=9Cwildca=
rd=E2=80=9D
notation in the file, where a wildcard implies that all children of the
wildcards parent are in fact public domain names themselves=E2=80=93excep=
t where
otherwise noted as a wildcard exception. For example, we use the
contrived entries in Table 1 to demonstrate this use of the PSL. These
entries result in the scopes shown in Table 2:

Name                 | Scope -------------------------------------
example              | Public foo.example          | Private
baz.foo.example      | Private bar.example          | Public
baz.bar.example      | Private www.baz.bar.example  | Private

Table 2: Domain name scope based on the PSL entries from Table 1.


The PSL effectively identifies scope. Of the 6,823 entries in the PSL at
the time of this writing, all but 50 are used to designate unbroken
public scope from TLDs to the entry itself. The remainder designate
public scope below a private domain. The primary function of the PSL,
therefore, is to delineate the highest boundary between public and
private domain space. Secondarily it identifies public/private
boundaries at arbitrary levels in the DNS namespace. The issue of
determining relationships between domains that are lineally connected
(i.e., one is an ancestor of another) and within the same public/private
scope is not addressed by the PSL, nor is the issue of cross-domain
relationships.


3.1 Usage

As alluded to previously, the PSL is used by several browsers, including
Mozilla Firefox, to identify domains as public or private. This is used
for validating the domain attribute of cookies. Additionally, it
provides visual and organizational convenience for readily identifying
the highest intra-scope private ancestor for a given private domain name.=

This is useful for organizing names and URLs by domain name, as in
bookmarks, and for highlighting key parts of URLs or certificates in the
address bar or other parts of the browser interface.

Existing DMARC implementations are known to use the PSL to assert
positive association of SPF- or DKIM-authenticated validated domain
names with the domain name corrsponding to the address in the =E2=80=9CFr=
om:=E2=80=9D
header. Inferred relationships are simply derived from intra-domain
relationships for which scope boundaries are not crossed.

DMARC implementations also use the public suffix to identify the highest
intra-scope ancestor of a (private) domain name for the purpose of
looking up the DMARC DNS record. The the appropriate ancestor name is
identified it is appended to the label dmarc to find the appropriate
information in the DNS.

SSL certificate authorities use the PSL to ensure that wildcards are not
issued for public domain names.


4 Problem Statement

The PSL is the primary resource for determining public/private
boundaries. Public domains in unbroken public scope, as well as those
under islands of private scope, can both be designated in the PSL.
However, that is the extent of its capabilities.

We propose the following with regard to domain relationships:

=E2=80=A2 Evaluate the effectiveness of the current PSL at performing the=

   functions within its scope.

=E2=80=A2 Evaluate the effectiveness of the maintenance and distribution
   of the PSL.

=E2=80=A2 Determine demand for domain relationship identification other
   than that provided by the PSL.

=E2=80=A2 Identify solutions to replace, extend, improve, or complement t=
he
   functionality, maintenance, or distribution of the PSL according
   to perceived demands.


4.1 Considerations

Considerations on evaluation of existing solutions and development of new=

solutions include the following:

Online vs. offline lookups:

Online publication and detection of domain relationships (e.g., as
entries in the DNS) has the advantage of rapid dissemination of changes.
Fresh information can be retrieved as soon as it has been published and
prior versions have expired. However, online publication can make offline=

lookups difficult or impossible. For a resource of capped scope, such as
the current PSL, embedding and periodic synchronization of the list for
offline use is feasible, e.g., through incremental or full transfer.
Online schemes for detecting other relationships might not have such
clear delineators, making offline use less practical. Additionally,
online detection can be chatty and add desired.

Centralized vs. distributed maintenance and distribution:

Centralized maintenance of a lookup service can be perceived as a
bottleneck, particularly for the general topic of domain name
relationships. If maintained in a distributed system, such as the DNS,
the burden and responsibility of updating is decentralized and falls
under the entity which controls the component of the service to which
the lookup is directed, allowing it to scale. However, if the scope is
fixed, as it is with the current PSL, scalability might not be a concern.=

In such cases, good practice, administered centrally, can potentially
outweigh the benefits of de-centralized service. For example, version
control and transparency, association of changes to a software release,
and general system consistency are all exemplified by the current PSL.

Scope and scalability associated with new generic TLDs:

While traditionally TLDs have been implicitly considered public scope,
the Internet Corporation for Assigned Names and Numbers=E2=80=99 (ICANN=E2=
=80=99s) new
generic TLD (gTLD) program [4] has introduced a new class of TLDs, whose
scope may differ from the norm. Depending on how delegations are handled
in each, this addition might raise new scalability questions with regard
to domain name scope boundaries (e.g., that provided by the PSL) or
general domain relationship identification.


Notes:

[1] <http://www.dmarc.org/>

[2] See the Certificate Authority (CA)/Browser Forum=E2=80=99s Ballot 74 =
for a
more detailed definition of =E2=80=9CDomain Authorization Document=E2=80=9D=
 at

<https://cabforum.org/2012/05/31/ballot74-updates-to-domain-and-ip-valida=
tion-high-risk-requests-and-data-source-in-the-baselinerequirements/>

[3] See <http://publicsuffix.org/>

[4] See <http://newgtlds.icann.org/en/>

end



From nobody Sun Nov  9 16:30:47 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0613A1A87C4 for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.232
X-Spam-Level: 
X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciCsrjHRAuib for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:30:44 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id D8BD21A87C3 for <dbound@ietf.org>; Sun,  9 Nov 2014 16:30:44 -0800 (PST)
Received: (qmail 30714 invoked by uid 0); 10 Nov 2014 00:30:44 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 10 Nov 2014 00:30:44 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with  id DcWg1p00N2UhLwi01cWjJN; Sun, 09 Nov 2014 17:30:43 -0700
X-Authority-Analysis: v=2.1 cv=F5TEKMRN c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=48vgC7mUAAAA:8 a=v_V_jhFd_orDZri4cwoA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=iyM2aDzDT+dK5n9FZa6RTs96Jcef+utf002FUD0+azw=;  b=7VyT3jD+VFi1w1RRxEBppwPwX/p1mdQw8SuLssta+PB1NKIFla9LENWK59FWQvgpw3P+k89fhWH9SLn/ed4vn5Mq0jMndzOvdBfocEtZmD8TIPNdsV61jPYP+fYLrAMp;
Received: from [24.5.2.144] (port=49583 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XncsT-0008Kj-IM for dbound@ietf.org; Sun, 09 Nov 2014 17:30:41 -0700
Message-ID: <54600756.1020501@KingsMountain.com>
Date: Sun, 09 Nov 2014 16:31:18 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TfcR6EK-O_k1GmDnnF89K3LJrD8
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 00:30:46 -0000

On Wed, 5 Nov 2014 09:36:30 -0500, Andreww Sullivan said:
 > On Wed, Nov 05, 2014 at 02:21:49PM +0000, Edward Lewis wrote:
 >>
 >> I guess what I=E2=80=99m saying is that I=E2=80=99m not so clear on w=
hy we are labeling
 >> domains as public or private.
 >
 > Your concern is precisely why, in my previous stabs at this, I have
 > attempted to avoid that.  It's the wrong classification, IMO, even if
 > it's a useful rule of thumb sometimes; and too much confusion has
 > resulted from trying to use it.

+1


 > Instead, we should be looking for a way of grouping identifiers
 > according to other classifications.  The motivating stuff in the
 > earlier I-Ds I wrote or worked on with Jeff is there to explain why
 > the DNS hierarchy is _not_ the right classification, despite the
 > attempts in the past to use it.

agreed.

e.g. please see..

Asserting DNS Administrative Boundaries Within DNS Zones
http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01

=2E.section 1 "Introduction and Motivation".


 > Unfortunately, to my way of thinking, people who have running code
 > that is already based on the faulty reading of the hierarchy are
 > unlikely to change that enough to work with new arbitrary groupings.
 > Moreover, there's the additional problem that allowing arbitrary links=

 > out of hierarchy will potentially explode the data that clients have
 > to pay attention to, and nobody is enthusiastic about that.

=2E.which are considerations to keep in mind as we explore use cases,=20
requirements, and potential solutions...

HTH,

=3DJeffH




From nobody Sun Nov  9 16:54:42 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B441A87DB for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDocsgTaDLVA for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 16:54:32 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id BF8DA1A8821 for <dbound@ietf.org>; Sun,  9 Nov 2014 16:54:29 -0800 (PST)
Received: (qmail 11820 invoked by uid 0); 10 Nov 2014 00:54:29 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 10 Nov 2014 00:54:29 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with  id DiuR1p00F2UhLwi01iuU6H; Sun, 09 Nov 2014 23:54:28 -0700
X-Authority-Analysis: v=2.1 cv=b7chvL2x c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=48vgC7mUAAAA:8 a=W0ucIhDPAAAA:8 a=5yPXWAip4Hoj-sGVga4A:9 a=QEXdDO2ut3YA:10 a=RmF4Z6CSgDUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=1SVlhAZ74ojKGE4MoXYiRzbgX8UsteK6Q2nvnxfLVgg=;  b=pjVvXfqvsSwD2pjdNvvvmXGxEZt/4WThVm3axlMmj+DKovBiFkygKJL5STHDz7SiiWgpMiMbNP+3nCMRnRTgFWewtxGGRXeAcRA+geE03kHwFmOlWC3xvT+FVZUqj2JG;
Received: from [24.5.2.144] (port=49732 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XndFS-0007Bc-1E for dbound@ietf.org; Sun, 09 Nov 2014 17:54:26 -0700
Message-ID: <54600CE7.2050808@KingsMountain.com>
Date: Sun, 09 Nov 2014 16:55:03 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/tEenXgWZ0Z6LzTap1oE6--zhqUw
Subject: [Dbound] fyi: HTTP cookie processing wrt "public suffixes"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 00:54:35 -0000

just fyi/fwiw, I wrote this up..

   [http-state] HTTP cookie processing wrt "public suffixes"
   http://www.ietf.org/mail-archive/web/http-state/current/msg01443.html

..which is of at least tangential interest in this (dbound) context. 
Working on the terminology section helped clarify to me (at least) some of 
the subtle differences between what are precisely top-level domains and what 
are, in the context of cookies and other browser internals, _not_ top-level 
domains but we are asked to treat them as such in said contexts.

e.g. see: https://publicsuffix.org/learn/  ("uses" section):
...
  Firefox

     Restricting cookie setting
     Restricting the setting of the document.domain property
     Sorting in the download manager
     Sorting in the cookie manager
     Searching in history
     Domain highlighting in the URL bar

  Chromium/Google Chrome (pre-processing, parser)

     Restricting cookie setting
     Determining whether entered text is a search or a website URL
...

..and note, just for fun, that the uses across these user agents isn't the 
same.

HTH,

=JeffH


From nobody Sun Nov  9 17:09:03 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFDE1A87E1 for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 17:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Level: 
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp1uBdTACbAY for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 17:08:56 -0800 (PST)
Received: from qproxy2-pub.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 9E0651A0037 for <dbound@ietf.org>; Sun,  9 Nov 2014 17:08:56 -0800 (PST)
Received: (qmail 3112 invoked by uid 0); 10 Nov 2014 01:08:55 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 10 Nov 2014 01:08:54 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id Dcor1p0072UhLwi01couqe; Sun, 09 Nov 2014 17:48:54 -0700
X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=Fwsyk3WOAnQA:10 a=pGLkceISAAAA:8 a=QLhupLqRAAAA:8 a=I0CVDw5ZAAAA:8 a=W0ucIhDPAAAA:8 a=yrh8Z8tmAAAA:8 a=40KA7GJGAAAA:8 a=38Vd-muwAAAA:8 a=48vgC7mUAAAA:8 a=LPtp3GjsYjlkh66SDEkA:9 a=QEXdDO2ut3YA:10 a=mGHSUJzIW_EA:10 a=gA6IeH5FQcgA:10 a=NWVoK91CQyQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=7lVLAkvdV2Xy/UuU1i1elyYO+CYmFIA+LxF7to+6nh8=;  b=Cn1a/n/ajSHYsCAymBl+AjWATFuOl1n+8RwS0BQ7OQ1f6af7wBuWa/o5OwfcSo0E/LeHpEVoAeb24sno9bXmfEv9Uvi48Cl5DjF51Y+vwj2bCQ3gfDfxr1AQW+YVOb8D;
Received: from [24.5.2.144] (port=49691 helo=[192.168.11.19]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XndA4-00010E-50 for dbound@ietf.org; Sun, 09 Nov 2014 17:48:52 -0700
Message-ID: <54600B99.5050704@KingsMountain.com>
Date: Sun, 09 Nov 2014 16:49:29 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.5.2.144 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/kbrpnTojDNSXp7U4iIvh8oj_bbU
Subject: Re: [Dbound] specific use cases & rationale ? (was: Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 01:08:59 -0000

Fri, 7 Nov 2014 13:44:37 -0500, Jeffrey Walton <noloader@gmail.com> said:
 >
 > On Fri, Nov 7, 2014 at 11:59 AM, Suzanne Woolf <suzworldwide@gmail.com> 
wrote:
 >>
 >> On Nov 5, 2014, at 4:47 PM, John Levine <johnl@taugh.com> wrote:
 >>
 >>>> I'm not sure why the IETF feels its OK to issue a certificate for
 >>>> *.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
 >>>> seen any reasoning.
 >>>
 >>> There are now vanity TLDs.  Why shouldn't a CA sign a cert for
 >>> *.neustar or *.williamhill if the TLD registrants (who are the same as
 >>> the registries) ask for them?
 >>> ...
 >>
 >> I had the same question John did. Isn't the question for the CA whether
 >> to issue a cert to the proper authority for the domain? TLDs have those
 >> just like domains further down the tree do.
 >>
 >> This actually further confuses me about why the cc/g distinction is
 >> important in this context.
 >
 > If I am reading it correctly, then there is no difference between
 > gTLDs and ccTLDs.

Possibly, depending on the use case and its context and perhaps not for your 
use case(s) -- tho more detail and rationale wrt your use cases would be 
possibly useful to the discussion (I'm curious).

there's some policy details here wrt "TLDs"..

https://www.iana.org/help/eligible-tlds


 > For my needs, I need to know how to recognize or detect gTLDs and
 > ccTLDs (and the vanities, as John pointed out). I also need to know
 > how to recognize second level domains, like *.co.uk (as someone else
 > mentioned).

why do you differentiate between so-called "2nd level domains" and TLDs?

Or is a short answer that everything that evaluates to being "public 
suffix"/eTLD according to https://publicsuffix.org/list/ satisfies the 
"needs" implied above?


 > Finally, it would be nice to know how to recognize
 > administrative boundaries, like between blogspot.com, foo.blogspot.com
 > and bar.blogspot.com.

yes, that's the more general approach that AndrewS and I have been working 
towards.

https://tools.ietf.org/html/draft-sullivan-zone-policy-assertions-01


 > I'm more concerned with the first two cases (gTLDs/ccTLDs and second
 > level domains). I'm concerned about these two cases because I have
 > witnessed attacks on them. A nice feature would be to avoid DNS and a
 > network call since each could be complicit in an attack on the TLD.
 > That's why I differentiate between top level/second level and the rest
 > of the zoo.

why are you assuming a network call here?  would not one have this info 
cached (as the browsers are doing (AFAIK))?


 > I'm less concerned with the administrative boundaries between, for
 > example, blogspot.com and foo.blogspot.com. Right now, I'm using a
 > PSL-like list for the administrative boundaries,

which list?

[ the fact that there's a bunch of PSL-like lists 'out there' is one of the 
driving issues for myself and Andrew ]


 > but I would like
 > something cleaner if its available.
 >
 > Finally, I need to know where to tell people to go look when their
 > software needs the same security controls. I can't say "You need to do
 > X" and not have a reference for X. I hope DBOUND will provide X so I
 > can say "You need to do X, and go look at DBOUND".

ultimately, yes, agreed.

HTH,

=JeffH


From nobody Sun Nov  9 17:37:07 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82B71A8869 for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 17:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRflHwqbA_zo for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 17:37:02 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16491A8833 for <dbound@ietf.org>; Sun,  9 Nov 2014 17:37:02 -0800 (PST)
Received: from mx1.yitter.info (dhcp-bfe9.meeting.ietf.org [31.133.191.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A57CB8A035 for <dbound@ietf.org>; Mon, 10 Nov 2014 01:37:01 +0000 (UTC)
Date: Sun, 9 Nov 2014 20:36:58 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141110013658.GB38381@mx1.yitter.info>
References: <545BE95F.3080601@KingsMountain.com> <545BED22.8070406@fifthhorseman.net> <CAEKtLiSe5KOmqaSqkgPUaq-egZRtt0if8mxxSirdsybAgoqw6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEKtLiSe5KOmqaSqkgPUaq-egZRtt0if8mxxSirdsybAgoqw6A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/efDPRuclp3gbuRnmUXKzDZUWoes
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 01:37:05 -0000

On Thu, Nov 06, 2014 at 05:06:33PM -0500, Casey Deccio wrote:
> time is not set in stone, and if there's sufficient interest/demand to move
> it to another time (or hold a "true" BoF), that could be arranged. 

The conflict with other WG sessions is also why I probably can't make
it, FWIW, but my schedule is pretty bad no matter what you do.

I'm pretty sure that the reason "real" BoFs came to have so much
ceremony around them was because scheduling these weeks is so hard.

A
-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Sun Nov  9 21:38:40 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E661A8912 for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 21:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIrlJUSJUTyQ for <dbound@ietfa.amsl.com>; Sun,  9 Nov 2014 21:38:37 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419CB1A890D for <dbound@ietf.org>; Sun,  9 Nov 2014 21:38:37 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id h11so9301448wiw.12 for <dbound@ietf.org>; Sun, 09 Nov 2014 21:38:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=pXNTvZMrzRD6TN7q1eu3OevSoClhBZXMGnd6xBhcyUM=; b=aU0cDQCEfix++g+hgeuR1gEknoyiKDwtHCbaCZZR3rMwvZgZ74Jyy7ajN4K2EBEWzs WO50zJojALgL9/1Eaq/VLz/rTDsnH9msigNmKTX+o+n4NvvMhyzmhQgSf7decP/tGLgr dsAg4vjqKyUHdiLKho60hzZw+c6nAAA3VtUY4=
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:content-type; bh=pXNTvZMrzRD6TN7q1eu3OevSoClhBZXMGnd6xBhcyUM=; b=HCqwGPL2q68i5l05jeCxAiXE+4iT9Ywttn7AicLyDJ5Ol27VCzQ0vw4X70jBrlc/H6 N1zuWXgNhyraOPuVWyRot6DAO1m3gAaLbe0q5eF4hVwuRRXpWmE8lCmxiEufT/gL/JKI xp2e1UyD/MfUkFyAIFVYZAEyZGf9PfcuwnzzwvgPFNzZo0GgGLuJd2gvJsg9NTCB5qeP x5ukH5uCKEWbhKp+Bt278H7U4TWo+en0c6X+EYzP3IBpHXmIcU0LuFUCrXkSZNJ3mkle kM8D4WaqXYsF1qJ6gua1AR+j+DgHwsroxD94TyWVh2AyMenD7vZTlRLkg64fzGDwnvdp YyEA==
X-Gm-Message-State: ALoCoQlUifUpfgq2mRvbLh6flcAdOOJkwsGS82k391TnoM6YlenGCpGltUzDGFbikXeG4fuZDwWt
MIME-Version: 1.0
X-Received: by 10.180.79.196 with SMTP id l4mr27608279wix.72.1415597916032; Sun, 09 Nov 2014 21:38:36 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Sun, 9 Nov 2014 21:38:35 -0800 (PST)
In-Reply-To: <20141110013658.GB38381@mx1.yitter.info>
References: <545BE95F.3080601@KingsMountain.com> <545BED22.8070406@fifthhorseman.net> <CAEKtLiSe5KOmqaSqkgPUaq-egZRtt0if8mxxSirdsybAgoqw6A@mail.gmail.com> <20141110013658.GB38381@mx1.yitter.info>
Date: Sun, 9 Nov 2014 19:38:35 -1000
X-Google-Sender-Auth: T_FbLAuSN255AJMHYDWEgyRebok
Message-ID: <CABuGu1pmW7eY8jv1S0eSkJbYoBfjJmWUSTe7KWCj2T1b_8vSNQ@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: dbound@ietf.org
Content-Type: multipart/alternative; boundary=f46d04428340ee29fd05077a9265
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/y2yeKV845kJQT2tGgukAxm-Kz_0
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 05:38:38 -0000

--f46d04428340ee29fd05077a9265
Content-Type: text/plain; charset=UTF-8

If it is feasible to find a time that does not conflict with UTA, that
would be great. There seems to be a lot of cross-interest between the two
topics - I have to count myself into that place of conflict too, though I
might land on the DBOUND side.

--Kurt Andersen

--f46d04428340ee29fd05077a9265
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If it is feasible to find a time that does not confli=
ct with UTA, that would be great. There seems to be a lot of cross-interest=
 between the two topics - I have to count myself into that place of conflic=
t too, though I might land on the DBOUND side.<br><br></div>--Kurt Andersen=
<br><br></div>

--f46d04428340ee29fd05077a9265--


From nobody Mon Nov 10 08:55:46 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560751A0183 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 08:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.022
X-Spam-Level: 
X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERof37g87d0w for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 08:55:42 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E0B1A017D for <dbound@ietf.org>; Mon, 10 Nov 2014 08:55:42 -0800 (PST)
Received: by mail-ig0-f177.google.com with SMTP id hl2so9447228igb.10 for <dbound@ietf.org>; Mon, 10 Nov 2014 08:55:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:date:message-id:subject:from:to:content-type; bh=vhCX2Lb13jI5ymMdD9dBMjZKJZetnAkhlaMHXXhpChE=; b=aE/Jgrl6/ybJYijnJpAI+Sf+PHGZ8uDlN2DToYt43ipRhed0QffDA5MH40PYycZNdL gQagjd09WqyJgOIHQF/oHirxaZl2hOhKPo9HJqRsnGV5JvTrCGb9HSUVX+/o7ECVRLcA g4D3fqFs1KnfseTxTn68sYSPQrj8fNp/igwmY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=vhCX2Lb13jI5ymMdD9dBMjZKJZetnAkhlaMHXXhpChE=; b=CnMnlKpqR5coKe+Cyz7P/DFlWWI5TvuXwwJH+VGKKk3IKah7nJDZzNKxp8yJYLAyF3 UnJWW+sJ7jFPpZNFMGNz0INxFxJm33SecngF6TuHZO3despKMuoG0qBHYmHtzcNDLj+x KLyqHNVmSpwPz0LfO0rLyre6IcxKXAk0Sn5BZR9aD6uH5pygqKALcJaBL5MqHrD2kdk6 UElwrO4oK09Vd9WsIYtGGm/dVqnFC4GRGah+0XKvIQ1VkHEdsPKwT2ckXXbTcz7KVAlv EZKHWrQDaNoAmr3fTON6nWhGGr6/5+1J8AMzFbKXhizdIcoe2ngYXb7a6gQkUm1CCdjB +BUg==
X-Gm-Message-State: ALoCoQlGwNnoeOeInU9N+BYRP3FdP15WBTBoJB1LqUy6acQyyx8EOB77iWSmgxuVFxzlpkaRjcfK
MIME-Version: 1.0
X-Received: by 10.107.11.129 with SMTP id 1mr34831839iol.18.1415638541881; Mon, 10 Nov 2014 08:55:41 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 10 Nov 2014 08:55:41 -0800 (PST)
Date: Mon, 10 Nov 2014 06:55:41 -1000
Message-ID: <CAEKtLiThr-j9yMScYDbAnBBgdwMb0PkgSkoYR-oV9ATXLX_uuQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a113de5866b6252050784085c
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/jhajMMcbLo9XPznVGxP13lc8gUI
Subject: Re: [Dbound] DBOUND bar BoF - doodle poll
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 16:55:44 -0000

--001a113de5866b6252050784085c
Content-Type: text/plain; charset=UTF-8

As there have been some requests to find alternative timing for the DBOUND
bar BoF, I've created a doodle poll to see if there's a time that generally
works better for folks:

http://doodle.com/neef2zviq9w4uyud

Note that the two daytime slots (one of which is the original) are during
official IETF sessions.  Note also that I have no venue selected for the
evening slots (not yet sure that the other meeting room is available that
late), and if one of those seems to work best I could really use help from
others in identifying some place suitable for the gathering (beach BoF?).

Please indicate your interest/availability on the poll by 1700 today, and
I'll plan to email the final time by 1800, so everyone can plan accordingly.

Thanks for your patience as we try to find a time to get a critical mass of
folks during a busy week of meetings and activities.

Casey

On Thu, Nov 6, 2014 at 7:27 AM, Casey Deccio <casey@deccio.net> wrote:

> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
>
> The objectives of the meeting are to review the principles and background
> behind domain boundaries, identify applications and protocols for which
> there is demand for such, and come up with a problem statement.  Since I've
> called for the BoF, I'll come up with a loose agenda for accomplishing
> this, but I'm happy to take feedback and suggestions from other interested
> parties.  I plan to use the proposed draft problem statement [1] as a
> starting place.
>
> Best regards,
> Casey
>
> [1] http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html
>

--001a113de5866b6252050784085c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As there have been some requests to find alternative =
timing for the DBOUND bar BoF, I&#39;ve created a doodle poll to see if the=
re&#39;s a time that generally works better for folks:<br></div><div><div><=
div><br><a href=3D"http://doodle.com/neef2zviq9w4uyud" target=3D"_blank">ht=
tp://doodle.com/neef2zviq9w4uyud</a><br><br></div><div>Note that the two da=
ytime slots (one of which is the original) are during official IETF session=
s.=C2=A0 Note also that I have no venue selected for the evening slots (not=
 yet sure that the other meeting room is available that late), and if one o=
f those seems to work best I could really use help from others in identifyi=
ng some place suitable for the gathering (beach BoF?).<br></div><div><br></=
div><div>Please indicate your interest/availability on the poll by 1700 tod=
ay, and I&#39;ll plan to email the final time by 1800, so everyone can plan=
 accordingly.<br></div><div><br>Thanks for your patience as we try to find =
a time to get a critical mass of folks during a busy week of meetings and a=
ctivities.<br></div><div><br>Casey<br></div></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Nov 6, 2014 at 7:27 AM, Case=
y Deccio <span dir=3D"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=
=3D"_blank">casey@deccio.net</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">A DBOUND bar BoF (i.e., unofficial IETF meeting)=
 will be held Tuesday morning 0900 - 1100 HST in Iolani Suite 3, in the Tap=
a Tower.<br><br>The objectives of the meeting are to review the principles =
and background behind domain boundaries, identify applications and protocol=
s for which there is demand for such, and come up with a problem statement.=
=C2=A0 Since I&#39;ve called for the BoF, I&#39;ll come up with a loose age=
nda for accomplishing this, but I&#39;m happy to take feedback and suggesti=
ons from other interested parties.=C2=A0 I plan to use the proposed draft p=
roblem statement [1] as a starting place. <br><br>Best regards,<br>Casey<br=
><br>[1] <a href=3D"http://www.ietf.org/mail-archive/web/dbound/current/msg=
00087.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/dbound/c=
urrent/msg00087.html</a><br></div>
</blockquote></div><br></div></div>

--001a113de5866b6252050784085c--


From nobody Mon Nov 10 12:04:22 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FDE1ACD6E for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 12:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XME-xxKddVwq for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 12:04:16 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42BD01ACD89 for <dbound@ietf.org>; Mon, 10 Nov 2014 12:03:49 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 10 Nov 2014 12:03:45 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 10 Nov 2014 12:03:45 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Draft problem statement and IETF "bar BoF"
Thread-Index: AQHP+EYDDL2A0rBKG0yMgkLTQ5z19pxREhWAgABtHoCAAMo0AIAAV+8AgAAW9ICAAA6jAIAABrcAgAABIwCAADwDAIAADtyAgALUNgD//9DnAIAAWq0AgAQXV4A=
Date: Mon, 10 Nov 2014 20:03:45 +0000
Message-ID: <D0863DBF.6BEA%edward.lewis@icann.org>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <D0828334.6AB9%edward.lewis@icann.org> <20141107193508.GE36019@mx1.yitter.info>
In-Reply-To: <20141107193508.GE36019@mx1.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [31.133.179.213]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3498458623_4082488"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/M6AnYHWhLAAnF6jN_nRCa1svwTk
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 20:04:19 -0000

--B_3498458623_4082488
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>On 11/7/14, 14:35, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
>
>>policy.  I pointed out that what they were really saying was that
>>every computer in the known universe had to be upgraded for this to
>>take effect.
>
>I wanted to respond - I don=B9t think that=B9s a foregone conclusion.  I know
>what you are saying, but there may be not-yet-written applications that
>could . . . it=B9s all conjecture.  Lacking any real example, it isn=B9t
>worth arguing past saying I=B9d also not rather assume a basic stub either.
>
>I.e., public vs. private is just something I wouldn=B9t assume is an
>adequate starting point.  Lacking a more elaborate =B3pony=B2 does not mean
>we can do the minimum and be happy.  (Along the lines of WhoIs-aka-port43
>had no authorization model which effectively forced a all-or-nothing
>model on us.)

(PS - Although this indented, it=B9s my reply.  I just don=B9t understand my
mail client.)

--B_3498458623_4082488
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTeq69grqt0ra7UgHyu
tSCe75NIAjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MTAyMDAzNDNaMA0GCSqGSIb3DQEBAQUABIIBAJyaY92ouHnOcraDWzMLEDySe9iu1AvhbHgY
xBNrj8yTAa3uTcc2xJ/EiD673UDX9QIj+fY0Sc1KJ3j0lEwaQltk1dqxV+OLTISxzsnvP7nB
oUnAa2iVdRWFArTjaWTGmr50s9y7wC4bbTT9nqCDZAiM1vFxNjd+hl8Bk9eMFwPMCU9UEdZA
lbjxyhfT9jzX1tm+AeOBPgNsL234pzAjPuCsP6vTSh/QJuBugZYmjbvOlszy3sYvoclp4UXh
3agk0EEqN76ckVUbjyC3XhSnByQSYxRZmn0CAbvjTyhC9TWMLo28ajPnHlTJ4t5NoHK2VeA5
Y06xTP5PWA6/NJLMgKE=

--B_3498458623_4082488--


From nobody Mon Nov 10 12:10:38 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096781A9042 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 12:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtbtDQ_i6mwU for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 12:10:29 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AEB1ACDA5 for <dbound@ietf.org>; Mon, 10 Nov 2014 12:10:18 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAAKAEHF006144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <dbound@ietf.org>; Mon, 10 Nov 2014 12:10:18 -0800
Message-ID: <54611BA3.6040008@dcrocker.net>
Date: Mon, 10 Nov 2014 12:10:11 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dbound@ietf.org" <dbound@ietf.org>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <D0828334.6AB9%edward.lewis@icann.org> <20141107193508.GE36019@mx1.yitter.info> <D0863DBF.6BEA%edward.lewis@icann.org>
In-Reply-To: <D0863DBF.6BEA%edward.lewis@icann.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 10 Nov 2014 12:10:18 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/I8VzVmjU3w8Lc7WWwgvx7mQGns0
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 20:10:31 -0000

I doubt this will be the kind of venue you'll hold the 'meeting' at, but
if the bar bof is actually going to be in a room and it is possible to
support remote participation, I'm interested.

Glad to supply my own bar food.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Nov 10 13:12:45 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF551ACEAF for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 13:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZmdtYZWTk_4 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 13:12:42 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C250E1ACD80 for <dbound@ietf.org>; Mon, 10 Nov 2014 13:12:41 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id x12so9998922wgg.4 for <dbound@ietf.org>; Mon, 10 Nov 2014 13:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=zE//1pPaRNt93fX6eB5ZFWvPwKvlv+QVpJoOmz6YpbI=; b=ANcN5GM0VYrBu0uMEhK/h0ApHzCtXh2VNKA/DonKRvt2+NWNBlqVbQ1Wnh+Cj0r/lK uFYR0fj++AfI3+FRcWfCQYjdA0Nq+8eUcUCq+LgF1vUDHnZewA2rei5voEeoMr2Jnyew Ihf5BZjvjrX5m0Q/p1GGb/RkCSK3YlyXAMHnk=
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:content-type; bh=zE//1pPaRNt93fX6eB5ZFWvPwKvlv+QVpJoOmz6YpbI=; b=BNmbFF84604E6OhfiMBKsAnESKaKc1y2cBB1jersw+XHnGXYBbsdodm3/mYDRyzunH 3cGdxnJ3KKgZJllyJG9gKdehMK8bvXQRdG1d8PVVz1Va0oeDmfmQfNme6Rm15KeyVQgH IIw1d5ENfo//bIDXSYkK4TcKRLdYkdqWjYWgSNdSTH9AOC0royVvoACwfeH2XQE1XZPJ wWcuOn70LZ4nN5LzDebcJwPJjPs1H4FcoKWZJzXZP3B71+2sDh+KOW7XyyVkEEPl0brE XFfg+dGhR1Pyz+YXT+hmJmdWCuc9jA6apGt/Wj6bAIjuLNgB2poxuFcsf1aepboUNxkb rdPQ==
X-Gm-Message-State: ALoCoQlG3OuJHfo64KePFgVnk/5IQatpUY0v3XDND6PMdFHHRZIbeHr5orOOsTE01e+jbiqKROt4
MIME-Version: 1.0
X-Received: by 10.180.186.175 with SMTP id fl15mr34932268wic.38.1415653960497;  Mon, 10 Nov 2014 13:12:40 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Mon, 10 Nov 2014 13:12:40 -0800 (PST)
In-Reply-To: <54611BA3.6040008@dcrocker.net>
References: <20141105214707.1557.qmail@ary.lan> <8BB69B3C-8A73-4C90-83ED-14DC66344B98@gmail.com> <D0828334.6AB9%edward.lewis@icann.org> <20141107193508.GE36019@mx1.yitter.info> <D0863DBF.6BEA%edward.lewis@icann.org> <54611BA3.6040008@dcrocker.net>
Date: Mon, 10 Nov 2014 11:12:40 -1000
X-Google-Sender-Auth: lcPdvGLEN8-OB0dYY-q-DIL-THo
Message-ID: <CABuGu1p4N_R4XJFeyBMCuwCBPO4SSdonSzyZeLLVbxxCYF2RBA@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a11339a6470d29f0507879f7a
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/31jweu95mcH7OU8_pcpWfSzgLj0
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 21:12:43 -0000

--001a11339a6470d29f0507879f7a
Content-Type: text/plain; charset=UTF-8

Seems like we should be able to secure a meeting room for the evening time
slots - I don't see a lot of contention for them.

--Kurt

--001a11339a6470d29f0507879f7a
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>Seems like we should be able to secure a meeting room for the evening time slots - I don&#39;t see a lot of contention for them.<br><br></div>--Kurt<br><br></div>

--001a11339a6470d29f0507879f7a--


From nobody Mon Nov 10 15:09:38 2014
Return-Path: <warren@kumari.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0FD1A88F7 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 15:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRICeuIw9jpr for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 15:09:33 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDCE1ACDF3 for <dbound@ietf.org>; Mon, 10 Nov 2014 15:09:33 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id x13so10256955wgg.33 for <dbound@ietf.org>; Mon, 10 Nov 2014 15:09:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oMq6r9V52oGgcU5GiMXn6WIFgddsvyNdVv8YdA20Qzs=; b=fUs0yWjG8rT1AjNTmoaCeqJJ98yyxaYDaQ9K4KsLOBu7OePKgrwhSUYDt+16aEWZoK 0hk6t2xj7HDE8iu/zW8LpEgH+zxQbSP5l0ZLM62ISfXjViwjyQEPOVUWc5sdxnLfTKX6 dShLl0AiPUzvIohH9XlmN4ntlpAdnrf1ogrrT/JfjDw9zz/OqIUfo1mpyuFWMMMJiYs3 0l7u1R8MjCM6o7HLoXn3FM/kdSV66u6tssiFM5d457SIHrjc/+XrEgtXUpJJM0kP8Pwa Se5+zSC46M/kvIJ6NWHEIDJrS8igNx+lL4UpwJ0s7UW993fszXFkiSOQfOsF6LNkjofB A5sg==
X-Gm-Message-State: ALoCoQkKRClteIjBiQTdiQwY41B/Q/IkehxNC54vJqFnl1aGKDOBy6+AbxayoZOQEMKrkgYiEmNj
MIME-Version: 1.0
X-Received: by 10.194.63.229 with SMTP id j5mr48173218wjs.23.1415660971883; Mon, 10 Nov 2014 15:09:31 -0800 (PST)
Received: by 10.194.64.37 with HTTP; Mon, 10 Nov 2014 15:09:31 -0800 (PST)
In-Reply-To: <545BE95F.3080601@KingsMountain.com>
References: <545BE95F.3080601@KingsMountain.com>
Date: Mon, 10 Nov 2014 13:09:31 -1000
Message-ID: <CAHw9_iJKy_wN31u3T_E_qdi6TK+=AtV0DhvZqGUXPz-8QrhhYA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/j1lsqeeDT8nqAW2NMWvZMxYyHWI
Cc: Casey Deccio <casey@deccio.net>, dbound@ietf.org
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 23:09:35 -0000

On Thu, Nov 6, 2014 at 11:34 AM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
>> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
>> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
>
> well, I'd like to participate but need to also attend UTA which is in that
> timeslot (based on UTA agenda I can perhaps skip the first hour of UTA
> unless they run ahead of schedule).
>
> how come a daytime slot and not an evening get-together? (but then y'all
> shouldn't make changes just for a slacker like me)

Yes, this confused me too -- I thought I couldn't come (because of
DPRIVE), but apparently that is next slot, so I think I can make it...

W

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Mon Nov 10 17:05:48 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC61A87E0 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 17:05:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kpEiUjEQ97c for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 17:05:44 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3B11A70FD for <dbound@ietf.org>; Mon, 10 Nov 2014 17:05:43 -0800 (PST)
Received: by mail-ig0-f179.google.com with SMTP id r10so140996igi.0 for <dbound@ietf.org>; Mon, 10 Nov 2014 17:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Az/3lZhAZGuJY+XPFigTbRhFphNBa8RxEZyjwTSBeEg=; b=X8aWjWWr7Faas735Bjzq8MVlHFLTdV2mIaig/t/L+yIfU09IYPD3sZ8cyMmWkclMFf 15qopLKmw2tl2TcPZjMY5Ar/Ow9flpxGgdtKmHxL9UV9vuoCtGFKlXoI7UECKYegHST1 9w5hQG/xzkLQdg8M7epF0TP7g1Co5q10GFw1Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Az/3lZhAZGuJY+XPFigTbRhFphNBa8RxEZyjwTSBeEg=; b=VQkRJU+OmvVvhCWG0O0+G+n0/EHMHu1NNkYjho24Bm6hzXMEEa4WXeYfmJ1TZHcP4c wBuIBFAASdgiUJXFcXoI7i18Oet4cXvmBbDL+nY/CPS6RwREyebcuaWhP5zqJYjUY9Q5 MdXBJslW2JI+O2AbKjZHRaWpNq+EmIN59co3AG1fhOaVhnPr3O0mK7bkHV4yyGFAMKw0 SqMticZoszmg0vu/baTUZFx2wbkBzG5zKC/iy+ZJO0/uG1NIeKjkhF89+dQCfP0C6eOG lVDR6kL1af/TqiC+HPNwF6HIprwa+CT+Q9hdA0XtSmjh5fE9QoGj6vTstvxqXT963AdG Hygg==
X-Gm-Message-State: ALoCoQn6QnLWW03+bk3kxGH+luZQULKsPHPsUU6yr+xyhFO4YlQOrR+9AFplqB+nq4G9AF8QgXVD
MIME-Version: 1.0
X-Received: by 10.107.40.141 with SMTP id o135mr22458759ioo.26.1415667941965;  Mon, 10 Nov 2014 17:05:41 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 10 Nov 2014 17:05:41 -0800 (PST)
In-Reply-To: <CAHw9_iJKy_wN31u3T_E_qdi6TK+=AtV0DhvZqGUXPz-8QrhhYA@mail.gmail.com>
References: <545BE95F.3080601@KingsMountain.com> <CAHw9_iJKy_wN31u3T_E_qdi6TK+=AtV0DhvZqGUXPz-8QrhhYA@mail.gmail.com>
Date: Mon, 10 Nov 2014 15:05:41 -1000
Message-ID: <CAEKtLiSZCo9UELn6Wf4bq2tEPHXaH4kekC9VLMsQN0ChY0b94w@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Warren Kumari <warren@kumari.net>
Content-Type: multipart/alternative; boundary=001a1141f010cd203905078ae0c4
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oTTwdWVMtY0jl-wdNgBBjeV-FhE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] DBOUND bar BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 01:05:45 -0000

--001a1141f010cd203905078ae0c4
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 10, 2014 at 1:09 PM, Warren Kumari <warren@kumari.net> wrote:

> On Thu, Nov 6, 2014 at 11:34 AM, =JeffH <Jeff.Hodges@kingsmountain.com>
> wrote:
> >> A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tuesday
> >> morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.
> >
> > well, I'd like to participate but need to also attend UTA which is in
> that
> > timeslot (based on UTA agenda I can perhaps skip the first hour of UTA
> > unless they run ahead of schedule).
> >
> > how come a daytime slot and not an evening get-together? (but then y'all
> > shouldn't make changes just for a slacker like me)
>
> Yes, this confused me too -- I thought I couldn't come (because of
> DPRIVE), but apparently that is next slot, so I think I can make it...


Please see the doodle poll:

http://doodle.com/neef2zviq9w4uyud

Cheers,
Casey

--001a1141f010cd203905078ae0c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 10, 2014 at 1:09 PM, Warren Kumari <span dir=
=3D"ltr">&lt;<a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@=
kumari.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div cla=
ss=3D""><div class=3D"h5">On Thu, Nov 6, 2014 at 11:34 AM, =3DJeffH &lt;<a =
href=3D"mailto:Jeff.Hodges@kingsmountain.com">Jeff.Hodges@kingsmountain.com=
</a>&gt; wrote:<br>
&gt;&gt; A DBOUND bar BoF (i.e., unofficial IETF meeting) will be held Tues=
day<br>
&gt;&gt; morning 0900 - 1100 HST in Iolani Suite 3, in the Tapa Tower.<br>
&gt;<br>
&gt; well, I&#39;d like to participate but need to also attend UTA which is=
 in that<br>
&gt; timeslot (based on UTA agenda I can perhaps skip the first hour of UTA=
<br>
&gt; unless they run ahead of schedule).<br>
&gt;<br>
&gt; how come a daytime slot and not an evening get-together? (but then y&#=
39;all<br>
&gt; shouldn&#39;t make changes just for a slacker like me)<br>
<br>
</div></div>Yes, this confused me too -- I thought I couldn&#39;t come (bec=
ause of<br>
DPRIVE), but apparently that is next slot, so I think I can make it...=C2=
=A0</blockquote><div><br>Please see the doodle poll:<br><br><a href=3D"http=
://doodle.com/neef2zviq9w4uyud" target=3D"_blank">http://doodle.com/neef2zv=
iq9w4uyud</a><br>=C2=A0</div>Cheers,<br>Casey<br></div></div></div>

--001a1141f010cd203905078ae0c4--


From nobody Mon Nov 10 22:07:44 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08A1AD007 for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 22:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJRbeDl11Yat for <dbound@ietfa.amsl.com>; Mon, 10 Nov 2014 22:07:36 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D551ACD85 for <dbound@ietf.org>; Mon, 10 Nov 2014 22:07:28 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id h3so437768igd.13 for <dbound@ietf.org>; Mon, 10 Nov 2014 22:07:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:date:message-id:subject:from:to:content-type; bh=1Y13hIONcYXNR70gULf03FVKx7rDNrgqHejq3Rfj9A8=; b=eMxkhOIAj+oOMWjt/hIeWFHqCZvVMdmhBBBR/Ng92LJx423rGgpUiP37lsdpyZFapH xRjp+W66l63QSqw+9xIzGPMmk6wKhGD7HDCKSqgzjWxTwoMc2lmEj+PdUWLRvp7XqfRD X9qBWXI6SWqfTTiBTZVALawWldoIZwbXxatzQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1Y13hIONcYXNR70gULf03FVKx7rDNrgqHejq3Rfj9A8=; b=ZgiWg+Fl7PsvRhdJVFf3Ndk4ruQlKJcqn2voEJvDG5zNSXu6Fk1Ht3uukGbTUHwzV/ ynXPjsj29wdLutTUIZZ1QVMVh2jlePDwf0aQWG7VhVVSlyGEQWHaZUiDgApYVpuguQXI CYT49xuSDm33ft8v4+HEKX+tdGteGXBsfm0LNRmOPBnlsfwkAqaZgiS2N5bz3RAiv7lZ Ip3KcFpxQYCVtqFWkE+9X3zqag6VVnzr2O/xIXDsu0M0qmL5nGkIA9mU0dK0ki52zY+C yYc5cNO0uMdqwZaFKaLdwXguP5XHv8v0nlD87jdVpfAJdreVqRHbdEubJy2kg/Qm+f5+ My2A==
X-Gm-Message-State: ALoCoQkr+UhHBSpFav+DhElAjrQw0A5h3ksQBGdvvrQn1E5y5wU1OjJfs72zGAiFHj1H9espRgto
MIME-Version: 1.0
X-Received: by 10.43.81.135 with SMTP id zy7mr6916727icb.63.1415686046365; Mon, 10 Nov 2014 22:07:26 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 10 Nov 2014 22:07:26 -0800 (PST)
Date: Mon, 10 Nov 2014 20:07:26 -1000
Message-ID: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>, apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=bcaec5186adee8558405078f1745
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/V6UjKWQGSxAfa7foAZj28pqHAU0
Subject: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 06:07:39 -0000

--bcaec5186adee8558405078f1745
Content-Type: text/plain; charset=UTF-8

[adding apps-discuss]

The time and location for the DBOUND meeting have changed.  The DBOUND side
meeting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on
Thursday in South Pacific II.  Thanks to Kurt Anderson for helping track
down a room.

The objectives of the meeting are to review the principles and background
behind domain boundaries, identify applications and protocols for which
there is demand for such, and come up with a problem statement.  Since I've
called for the meeting, I'll come up with a loose agenda for accomplishing
this, but I'm happy to take feedback and suggestions from other interested
parties.  I plan to use the proposed draft problem statement [1] as a
starting place.

Best regards,
Casey

[1] http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html

P.S. If anyone is unable to meet at the designated time, I'm happy to meet
up earlier to discuss the subject ahead of time, which perspectives can be
incorporated into the later meeting.  I'll be available in Iolani 3 (Tapa
Tower) at 0900 tomorrow (the original proposed time).

--bcaec5186adee8558405078f1745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">[adding apps-discuss]<br><div><div><br></div><div>The time=
 and location for the DBOUND meeting have changed.=C2=A0 The DBOUND side me=
eting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on Thursd=
ay in South Pacific II.=C2=A0 Thanks to Kurt Anderson for helping track dow=
n a room.<br></div><div><br>The
 objectives of the meeting are to review the principles and background=20
behind domain boundaries, identify applications and protocols for which=20
there is demand for such, and come up with a problem statement.=C2=A0 Since=
=20
I&#39;ve called for the meeting, I&#39;ll come up with a loose agenda for=
=20
accomplishing this, but I&#39;m happy to take feedback and suggestions from=
=20
other interested parties.=C2=A0 I plan to use the proposed draft problem=20
statement [1] as a starting place. <br><br>Best regards,<br>Casey<br><br>[1=
] <a href=3D"http://www.ietf.org/mail-archive/web/dbound/current/msg00087.h=
tml" target=3D"_blank">http://www.ietf.org/mail-archive/web/dbound/current/=
msg00087.html</a><br><br>P.S. If anyone is unable to meet at the designated=
 time, I&#39;m happy to meet up earlier to discuss the subject ahead of tim=
e, which perspectives can be incorporated into the later meeting.=C2=A0 I&#=
39;ll be available in Iolani 3 (Tapa Tower) at 0900 tomorrow (the original =
proposed time).<br></div></div></div>

--bcaec5186adee8558405078f1745--


From nobody Tue Nov 11 00:07:42 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C501AD5D3 for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 00:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cns0vF8YpDAI for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 00:07:30 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F48E1AD5E2 for <dbound@ietf.org>; Tue, 11 Nov 2014 00:07:30 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id tp5so11003546ieb.29 for <dbound@ietf.org>; Tue, 11 Nov 2014 00:07:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qmx5Iemcl0EvDmmO64kodfz1rPBXbHS6tKFaVc3gPL0=; b=go8KIeU0cEb2t0rqAWNxDEeU8cGfjfVeRXhi9Nf1ZWXkfbV+X8dC4GhSaxqpS8wmVh 16mGFhgDwl7KP1u8HT/sNwQk1c44MgDXtIMDd+B+PgQGfRnDfmyTPYKMM5otBG72MaWf AMBcZ0OBezN0EaXtDQSdRB7yEyYHDY4CNkX4U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qmx5Iemcl0EvDmmO64kodfz1rPBXbHS6tKFaVc3gPL0=; b=V3vqs8iES4sz9AQVi87K71SaFdCENivMPpuCX7VcxH8n4dxQ1T3D6RK+RQfF4UPyI+ tTyDRf/ZyWtr2kJHuNWcANkXFknAuSq6lPpMYbpHO9dsNmRUX2gk1fAkNV6gfD2EY2bV PMWlPuk8Hycm2wxpKrG8LJm2k++Jy8IJD2ssBZuERABwP0wM9e40GJBvdF8o6JbTH4Nz LfBU1Y0r0BXjext0IyNtR09iAE8BV25rbOGTWcSHetwAD5zVWJGAc04KAtuKZ1NFaUgw 2r6Uvs6G31lshvnMWJ6cXUtlCRORABOoPrdWsY/6Yhu46FH/gISVBY5aPMpdeD4ataTJ +rWg==
X-Gm-Message-State: ALoCoQnd8VqcxduMWTZMxHfkQChdA2hxi1GN1X4t8HDAj0Pjg4F7/IKE5vwlc71qwFcC2MZUDhAY
MIME-Version: 1.0
X-Received: by 10.107.5.79 with SMTP id 76mr1830010iof.74.1415693249238; Tue, 11 Nov 2014 00:07:29 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 11 Nov 2014 00:07:29 -0800 (PST)
In-Reply-To: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>
References: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>
Date: Mon, 10 Nov 2014 22:07:29 -1000
Message-ID: <CAEKtLiSD_LM8s_dKzX4XN-4_QKKUpgNwsgJN0+HPiiCGuetCiQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>, apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=001a113ee6463b7530050790c502
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/joRz6SatX4yhNqzXOVJWsBhbPSw
Subject: Re: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 08:07:32 -0000

--001a113ee6463b7530050790c502
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <casey@deccio.net> wrote:

> The time and location for the DBOUND meeting have changed.  The DBOUND
> side meeting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on
> Thursday in South Pacific II.
>

*sigh*.  The start time should read *1640* (i.e., 4:40pm).

Casey

--001a113ee6463b7530050790c502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <span dir=3D=
"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@decci=
o.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The time and loca=
tion for the DBOUND meeting have changed.=C2=A0 The DBOUND side meeting (as=
 opposed to (non) bar BoF) will be held from 1440 - 1910 on Thursday in Sou=
th Pacific II.<br></div></blockquote><div><br></div><div>*sigh*.=C2=A0 The =
start time should read *1640* (i.e., 4:40pm).<br><br>Casey<br></div></div><=
/div></div>

--001a113ee6463b7530050790c502--


From nobody Tue Nov 11 08:43:15 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FAB1A003B; Tue, 11 Nov 2014 08:43:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRusEwEEHBuD; Tue, 11 Nov 2014 08:43:10 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3931D1A0016; Tue, 11 Nov 2014 08:43:10 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABGh5vE015967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 08:43:09 -0800
Message-ID: <54623C95.1090303@dcrocker.net>
Date: Tue, 11 Nov 2014 08:43:01 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>, "dbound@ietf.org" <dbound@ietf.org>, apps-discuss@ietf.org
References: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com> <CAEKtLiSD_LM8s_dKzX4XN-4_QKKUpgNwsgJN0+HPiiCGuetCiQ@mail.gmail.com>
In-Reply-To: <CAEKtLiSD_LM8s_dKzX4XN-4_QKKUpgNwsgJN0+HPiiCGuetCiQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 11 Nov 2014 08:43:09 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/QmrUVA1f8n5bwKpIxPV97jSiuHU
Subject: Re: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 16:43:12 -0000

On 11/11/2014 12:07 AM, Casey Deccio wrote:
>     The time and location for the DBOUND meeting have changed.  The
>     DBOUND side meeting (as opposed to (non) bar BoF) will be held from
>     1440 - 1910 on Thursday in South Pacific II.
> 
> 
> *sigh*.  The start time should read *1640* (i.e., 4:40pm).

4 1/2 hours?

Any chance of an audio link for remote access?  That room isn't on the
list of regular audio.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 11 09:20:22 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476FD1A00CA for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 09:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sLd7INGzqk6 for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 09:20:07 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42F31A00E9 for <dbound@ietf.org>; Tue, 11 Nov 2014 09:20:03 -0800 (PST)
Received: by mail-ig0-f169.google.com with SMTP id hn18so1448574igb.0 for <dbound@ietf.org>; Tue, 11 Nov 2014 09:20:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EPDzTZm/Jw9o+9tH8s68Y6kExCOp1AN4uBDvS1DKYGw=; b=TTa1alS1rF/v7omNaOvRvN7aDsS1GheahHy9+6vmsd7Vf2owQ7DImIQVI07q0WYpNI j+A1erj3SaIVIrdelL4DNhC9HXOegqy7tHwEuKSfHakok5ToUPl9QRFanE9IfXj5MKoT 3sIRC3laf7N5SEoXyiWfCTwEaqIwkxx2JHTA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EPDzTZm/Jw9o+9tH8s68Y6kExCOp1AN4uBDvS1DKYGw=; b=US8bwHot7PqesqW4ZkGJd2RpSjp5mvcdMgQBnS/YuJTkPRY/fL0VYdkNx9/L29ljy8 2M9SBv/0u5J2grZlsu6iixkm14hWMPlaGmt8trJ9wKx/NtMzZuRcp/bcK31XzNfZl4dT oN9B5zatSZYOkgww6+sE0AJN6FunBcJtb+4rUQIc6EBsjAfQOFcz+XPkk4N3OldJRiGz PyigCXBm/hdCdsYB/wGoU7WjzzvGdngHOdrjNpsdrGSmVcVM9jd04ddRqGluM5aGR30s c36CUWRHspL1E6LWQMdJ5HS3kZOCMB0lSv6UC/tzmxVxZcOMFTyZoOS8Z0lOFXUQ5g8h m4Lw==
X-Gm-Message-State: ALoCoQnMnT9FKDZFYgMuwT8IZ6x9P2cSBaeB6+FXj6M+npaZcefrQK0DZiUztIZthvZdTbNQU5Fr
MIME-Version: 1.0
X-Received: by 10.42.184.74 with SMTP id cj10mr3123244icb.80.1415726403138; Tue, 11 Nov 2014 09:20:03 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 11 Nov 2014 09:20:03 -0800 (PST)
In-Reply-To: <54623C95.1090303@dcrocker.net>
References: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com> <CAEKtLiSD_LM8s_dKzX4XN-4_QKKUpgNwsgJN0+HPiiCGuetCiQ@mail.gmail.com> <54623C95.1090303@dcrocker.net>
Date: Tue, 11 Nov 2014 07:20:03 -1000
Message-ID: <CAEKtLiQi8oXp8qouXRGaUohznGuAS--R-YV==mvFLeQ76k6bFA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: dcrocker@bbiw.net
Content-Type: multipart/alternative; boundary=20cf303f6ea85bd2a20507987d60
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4qRaBSx1IFMFkwugJNwymN5M0zc
Cc: apps-discuss@ietf.org, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 17:20:08 -0000

--20cf303f6ea85bd2a20507987d60
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 11, 2014 at 6:43 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 11/11/2014 12:07 AM, Casey Deccio wrote:
> >     The time and location for the DBOUND meeting have changed.  The
> >     DBOUND side meeting (as opposed to (non) bar BoF) will be held from
> >     1440 - 1910 on Thursday in South Pacific II.
> >
> >
> > *sigh*.  The start time should read *1640* (i.e., 4:40pm).
>
> 4 1/2 hours?
>

My communication skills are being challenged with this announcement.  The
correct start and end times for the meeting are:

1640 - 1910 HST (2.5 hours)

Any chance of an audio link for remote access?  That room isn't on the
> list of regular audio.
>
>
I will check around to see if there's something available.

Cheers,
Casey

--20cf303f6ea85bd2a20507987d60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 11, 2014 at 6:43 AM, Dave Crocker <span dir=3D=
"ltr">&lt;<a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocke=
r.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/11/2014 12:=
07 AM, Casey Deccio wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0The time and location for the DBOUND meeting have c=
hanged.=C2=A0 The<br>
&gt;=C2=A0 =C2=A0 =C2=A0DBOUND side meeting (as opposed to (non) bar BoF) w=
ill be held from<br>
&gt;=C2=A0 =C2=A0 =C2=A01440 - 1910 on Thursday in South Pacific II.<br>
&gt;<br>
&gt;<br>
&gt; *sigh*.=C2=A0 The start time should read *1640* (i.e., 4:40pm).<br>
<br>
</span>4 1/2 hours?<br></blockquote><div><br></div><div>My communication sk=
ills are being challenged with this announcement.=C2=A0 The correct start a=
nd end times for the meeting are:<br><br></div><div>1640 - 1910 HST (2.5 ho=
urs)<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any chance of an audio link for remote access?=C2=A0 That room isn&#39;t on=
 the<br>
list of regular audio.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I will check around to see if there&#39;s something =
available.<br><br></div><div>Cheers,<br>Casey<br></div></div></div></div>

--20cf303f6ea85bd2a20507987d60--


From nobody Tue Nov 11 09:26:07 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131E81A00E9; Tue, 11 Nov 2014 09:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtK2F15g2HMq; Tue, 11 Nov 2014 09:26:04 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F359B1A00E6; Tue, 11 Nov 2014 09:26:00 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABHPpsE017395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 09:25:54 -0800
Message-ID: <5462469B.6040903@dcrocker.net>
Date: Tue, 11 Nov 2014 09:25:47 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>, dcrocker@bbiw.net
References: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>	<CAEKtLiSD_LM8s_dKzX4XN-4_QKKUpgNwsgJN0+HPiiCGuetCiQ@mail.gmail.com>	<54623C95.1090303@dcrocker.net> <CAEKtLiQi8oXp8qouXRGaUohznGuAS--R-YV==mvFLeQ76k6bFA@mail.gmail.com>
In-Reply-To: <CAEKtLiQi8oXp8qouXRGaUohznGuAS--R-YV==mvFLeQ76k6bFA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 11 Nov 2014 09:25:55 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/x3xrqzNC7Wyua0IYji0ChMAp_IA
Cc: apps-discuss@ietf.org, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 17:26:06 -0000

On 11/11/2014 9:20 AM, Casey Deccio wrote:
>     Any chance of an audio link for remote access?  That room isn't on the
>     list of regular audio.
> 
> 
> I will check around to see if there's something available.


Thanks!

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 11 10:50:43 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C551A1A74 for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 10:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KtuiqauX1Rh for <dbound@ietfa.amsl.com>; Tue, 11 Nov 2014 10:50:31 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5541A1AAB for <dbound@ietf.org>; Tue, 11 Nov 2014 10:50:29 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id h11so2570217wiw.6 for <dbound@ietf.org>; Tue, 11 Nov 2014 10:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w0u4wg8ryjTgHxvEv3GhANRiFxO+V7RALYlIdo7nwr0=; b=QUPZ9zg9Yq+m8Z1FnnZZUY7+istxyuMkKOqgdznZDxDkKU71qp88E361bQxaeOwVXG u8ywsiL6alljJccMKUkElwZWJ06A/zVRzpnLj1xYaDu15edK3FFepTCgT3nLFsZSEH1C zLffpDxSNXka+mymAaNahN0vkMHdHGOF4YTO0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w0u4wg8ryjTgHxvEv3GhANRiFxO+V7RALYlIdo7nwr0=; b=U1ZIHXxZKKEJW1f0mACi8idzuJqkq2xwu4IjF74HswI+nXlMyEE9w38jKfSJMa4onU +b2r2l6YwsdLtYy4Kw+LIEXZY+BW2At/yFdFixk99pYrEg1ulMWipVOesV7gWwEH6554 kMEFkVAywygKQ95oOPz7AztFw89991KH4m4Nac4eCh4zFUmwb2eLTzA51bf+Y2Krzuul WMlICUjVqMix7rXfZ91Y1BVYB7Vkaij3Yym+9smY5xsdXeYGBVTXVXzrbwwgPDSnjE7X j/Ayjg5C9abR/E/rS0hKm6nowvqbNW33VPeAkHRKbkNTJLTyIORAhAlXsoLHA0LatOYJ pl7w==
X-Gm-Message-State: ALoCoQl7BBtukgqPIwPD2IEoRpX2tjMis4wJd+Wh7I6YGiIDQV2StyA0rDV4aqfzg5eZz7vBeJcY
MIME-Version: 1.0
X-Received: by 10.180.84.198 with SMTP id b6mr43667282wiz.41.1415731827865; Tue, 11 Nov 2014 10:50:27 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Tue, 11 Nov 2014 10:50:27 -0800 (PST)
In-Reply-To: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>
References: <CAEKtLiR8y-yUXb196QpwyQqvbZQnSAxSGG5Oqpgs7Wic=YpdOQ@mail.gmail.com>
Date: Tue, 11 Nov 2014 08:50:27 -1000
X-Google-Sender-Auth: Rv46ijAnA75ZF8bH9va9L8rNpOY
Message-ID: <CABuGu1q_hx9E0hwR0henkhjD=kh=S+Y1qDcQ4kW8urjrE2qJyg@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: multipart/alternative; boundary=f46d0418264ab2cdad050799c0b6
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ayz_8HtdWnZlmRwCG8Fd7dGyff4
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] DBOUND side meeting - new time/location
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 18:50:33 -0000

--f46d0418264ab2cdad050799c0b6
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <casey@deccio.net> wrote:

> . . .The DBOUND side meeting (as opposed to (non) bar BoF) will be held
> from 1640 - 1910 HST (UTC-1000) on Thursday in South Pacific II.
>

For those who wish to participate remotely, we will have an audio feed via
a polycom phone in the room. Please connect to:

To join via Browser: https://bluejeans.com/966106876/browser
Or to join via Phone:
1) Dial:
+1 408 740 7256
+1 888 240 2560(US Toll Free)
+1 408 317 9253(Alternate Number)
(see all numbers - http://bluejeans.com/numbers)
2) Enter Conference ID: 9661-06876

--Kurt Andersen

--f46d0418264ab2cdad050799c0b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <span dir=3D=
"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@decci=
o.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">. . .The DBOUND side meeting (as opposed to (non) bar BoF) will be held f=
rom 1640 - 1910 HST (UTC-1000) on Thursday in South Pacific II.=C2=A0 <br><=
/div></blockquote><br></div><div class=3D"gmail_quote">For those who wish t=
o participate remotely, we will have an audio feed via a polycom phone in t=
he room. Please connect to:<br><br>To join via Browser: <a href=3D"https://=
bluejeans.com/966106876/browser">https://bluejeans.com/966106876/browser</a=
><br>Or to join via Phone:<br>1) Dial:<br>          +1 408 740 7256<br>    =
      +1 888 240 2560(US Toll Free)<br>          +1 408 317 9253(Alternate =
Number)<br>          (see all numbers - <a href=3D"http://bluejeans.com/num=
bers">http://bluejeans.com/numbers</a>)<br>2) Enter Conference ID: 9661-068=
76<br></div><br></div><div class=3D"gmail_extra">--Kurt Andersen<br></div><=
/div>

--f46d0418264ab2cdad050799c0b6--


From nobody Wed Nov 12 07:29:17 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372671A1B18 for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 07:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQU2opV_YG_8 for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 07:29:12 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887FB1A1B47 for <dbound@ietf.org>; Wed, 12 Nov 2014 07:29:07 -0800 (PST)
Received: from [86.172.148.252] (port=58201 helo=[192.168.1.72]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1XoZqz-00081j-Gp; Wed, 12 Nov 2014 15:29:05 +0000
Message-ID: <54637CBE.4010908@mozilla.org>
Date: Wed, 12 Nov 2014 15:29:02 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>	<54591324.3040803@mozilla.org>	<CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com>	<5459FA73.40208@mozilla.org> <CAEKtLiTOcUAzRx6TuJGKKWecGwW5PijPS2CCmZ5Qh61TCeW2_Q@mail.gmail.com>
In-Reply-To: <CAEKtLiTOcUAzRx6TuJGKKWecGwW5PijPS2CCmZ5Qh61TCeW2_Q@mail.gmail.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oGzzB_sHHsZQhIox2uFGRXeNTZI
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Nov 2014 15:29:14 -0000

On 05/11/14 14:40, Casey Deccio wrote:
> I'm wondering if that is the confusion with the most recent point as
> well.  Is it possible that you were looking at the entry "foo.example"
> in Table 2 and forgetting that it matched the wildcard exception (i.e.,
> was not in the same category as "fred.example" and "bar.example"), just
> as the wildcard exception for "foo.example" was overlooked when you
> contrived your own example (and they ultimately clashed)?

Yes, indeed. This was it.

> On a related point, there was some question as to whether entries for
> "example" and "*.example" were both useful in the list.  You indicated
> that they were not (and I can see that is the case in the current PSL,
> both by entries and by testing), and my initial response was agreement. 
> However, it is not clear to me from the specified algorithm that
> "*.example" implies "example".  If that implication is intentional, then
> it seems inconsistent with the specification as I read it: "The wildcard
> character * (asterisk) matches any valid sequence of characters in a
> hostname part" and "Wildcards may only be used to wildcard an entire
> level" [1].

"*.example" does indeed NOT imply "example", or any shorter rule in
fact. However, if the number of labels in the two rules you are looking
at differs by only 1, what does it mean to list them both? In this case,
when would the "example" rule ever get matched? Only by http://example/
- but then such dotless names normally don't get checked against the PSL
anyway, as it's assumed that they are intranet names.

Gerv


From nobody Wed Nov 12 12:20:27 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB81A8730 for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 12:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhFNRM73yxZU for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 12:20:22 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 40F2F1A6FDE for <dbound@ietf.org>; Wed, 12 Nov 2014 12:20:19 -0800 (PST)
Received: (qmail 27643 invoked by uid 0); 12 Nov 2014 20:20:17 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 12 Nov 2014 20:20:17 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id EkLB1p00U2UhLwi01kLEku; Wed, 12 Nov 2014 13:20:15 -0700
X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=4BreF0GzsJ0A:10 a=48vgC7mUAAAA:8 a=TdaMsjFkkgzCVgG133AA:9 a=QEXdDO2ut3YA:10 a=t46s43q7nKIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=20bl8NGFjAnLzpXh2qPVsSjQerlg7FscL5wwsZ8jYrI=;  b=fbrjOG+0VdqqXsbG/6w7ksmVhw1S4PjQm31tRUVizWIxss5K6IoxUVtvDbaZPY40mJz+DwWa/7mfgD7rIHnMPgY04upU5Vf12bZqsrcpWIzPyySq+un+4o73fZSpGs1m;
Received: from [31.133.132.6] (port=50456) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XoeOi-0005Zw-44; Wed, 12 Nov 2014 13:20:12 -0700
Message-ID: <5463C0F5.5090301@KingsMountain.com>
Date: Wed, 12 Nov 2014 12:20:05 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.132.6 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/G1Fad35TeT69d0fDnfhpqmdDqBI
Cc: Gervase Markham <gerv@mozilla.org>
Subject: Re: [Dbound] handling of single-label DNS Names (was: Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Nov 2014 20:20:23 -0000

 >> On a related point, there was some question as to whether entries for
 >> "example" and "*.example" were both useful in the list.  You indicated
 >> that they were not (and I can see that is the case in the current PSL,
 >> both by entries and by testing), and my initial response was agreement.
 >> However, it is not clear to me from the specified algorithm that
 >> "*.example" implies "example".  If that implication is intentional, then
 >> it seems inconsistent with the specification as I read it: "The wildcard
 >> character * (asterisk) matches any valid sequence of characters in a
 >> hostname part" and "Wildcards may only be used to wildcard an entire
 >> level" [1].
 >
 > "*.example" does indeed NOT imply "example", or any shorter rule in
 > fact. However, if the number of labels in the two rules you are looking
 > at differs by only 1, what does it mean to list them both? In this case,
 > when would the "example" rule ever get matched? Only by http://example/
 > - but then such dotless names normally don't get checked against the PSL
 > anyway, as it's assumed that they are intranet names.


Note also that the above is the gist of Adam Barth's reply/contribution to 
the "HTTP cookie processing wrt "public suffixes"" thread over on http-state@

Re: [http-state] HTTP cookie processing wrt "public suffixes"
http://www.ietf.org/mail-archive/web/http-state/current/msg01444.html


=JeffH




From nobody Wed Nov 12 12:27:41 2014
Return-Path: <tim@eudaemon.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844101A19EC for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 12:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level: 
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snTD1EoJiOIc for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 12:27:39 -0800 (PST)
Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 159601A0A6B for <Dbound@ietf.org>; Wed, 12 Nov 2014 12:27:35 -0800 (PST)
Received: from dhcp-a558.meeting.ietf.org (dhcp-a558.meeting.ietf.org [31.133.165.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 4CC67CB46; Wed, 12 Nov 2014 15:27:33 -0500 (EST)
From: Tim Draegen <tim@eudaemon.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Nov 2014 10:27:32 -1000
To: Dbound@ietf.org
Message-Id: <B5FA705E-9DFE-4B37-A6EE-50C1E5B5B6B7@eudaemon.net>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6wvs8V1_W2Ffcxtv0GrNWAGlrpk
Subject: [Dbound] algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Nov 2014 20:27:40 -0000

Hi, in reviewing the draft problem statement, I=E2=80=99d like to add =
some meat to Section 4, sub-bullet #4, which is:

=E2=80=A2 Identify solutions to replace, extend, improve, or complement =
the
  functionality, maintenance, or distribution of the PSL according
  to perceived demands.

In my adventures I've come across a similar chunk of PSL-like =
functionality, specifically in the land of PassiveDNS:

  =
https://archive.farsightsecurity.com/Passive_DNS/passive-dns-architecture.=
pdf

Section 2.4 of this PDF ("Bailiwick reconstruction") goes through and =
describes an algorithm that yields oddly similar results to the PSL....  =
at least in the context of DMARC.

I have a relatively large pile of data against which I'll be pitting PSL =
vs Bailiwick to see where the two approaches diverge.  If nothing else =
this might spur discussion and/or inform opinions.

=3D- Tim

* http://www.ietf.org/mail-archive/web/dbound/current/msg00141.html


From nobody Wed Nov 12 13:17:12 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C821AD39A for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 13:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OejiGNK07YQu for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 13:17:09 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBCF1ACEE1 for <dbound@ietf.org>; Wed, 12 Nov 2014 13:17:09 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hi2so6247285wib.13 for <dbound@ietf.org>; Wed, 12 Nov 2014 13:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=m78GV0JjKZlYuRIxE8eXp35lf2gdhCuCdP2rc/iEpK0=; b=JW89p201WsW8edwPQ43NrBOx+D7K4qIe28sCiozljkLpz+kWLTNu+bfy5w7Q0tXr8Z yiUC20HVuvxR/BM7xo7MjmJK5LJbgA1YzRIYxgqqcHugw5zYBvHtBt4Yhqmm0uU/R1pH CrngsSrS/TSE8IBPErtbZRkpM8R7XNyQI0g0s=
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:content-type; bh=m78GV0JjKZlYuRIxE8eXp35lf2gdhCuCdP2rc/iEpK0=; b=UBjkvn3Je72nkjkee2DEu88uiS1tdeudBOs/LVltWYauqtK985Qvs04V0g1ZIGBjQy A++9jbXzoyd+RezoT+24S6OGF1OssoFDD6xAQHaTnL77pxqgwveIsK7POxnxSYAz4O9F l3xoywOrxhLsJwn3IPP4/4+HUtnhUgGcgDpVoayMFD0MR69e4Or/l7lWWqalEcPJM16B xbjIA8tzwpWmo4uUylhCWBudW4Ued6y0KCE03meOkdvIvUE7eSl+O/PqMak1STS15GTN 1RHqdzRlOWgqM+6IKtu2w+HQFbdZyeJhbk0d0gAc/pTghcXGlWnlOgaXlG4wzoWv0VN3 VhNw==
X-Gm-Message-State: ALoCoQn/D6iYTZ9VVS17qphm+m3MpmpnWtCKjL5WwpjAuHxzlAwxnywfqrMmnI1VauaWvu9XugSl
MIME-Version: 1.0
X-Received: by 10.194.109.226 with SMTP id hv2mr66766352wjb.45.1415827027823;  Wed, 12 Nov 2014 13:17:07 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Wed, 12 Nov 2014 13:17:07 -0800 (PST)
In-Reply-To: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com>
Date: Wed, 12 Nov 2014 11:17:07 -1000
X-Google-Sender-Auth: QoJEKzUbm5jEkaQf0u2x0TCfV-U
Message-ID: <CABuGu1rkQfKQZia78QPkHEkC8DHczTaUuX5gm7yqFunhook7hw@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=089e0102fc4c0e9b9e0507afeb00
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/F7GYe-gV_-zBkuqu4kF1SCt0OGs
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Nov 2014 21:17:11 -0000

--089e0102fc4c0e9b9e0507afeb00
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 4, 2014 at 5:42 AM, Casey Deccio <casey@deccio.net> wrote:

>
> Please find attached a draft DBOUND problem statement. . .
>

Having had time to consider this write up (in the midst of all the IETF
traffic), I appreciate the work to clarify the scope and semantics, but it
seems like the problem summary puts the cart before the horse.

Taking the liberty of numbering the existing list:

   1. Evaluate the effectiveness of the current PSL at performing the
   functions within its scope.
   2. Evaluate the effectiveness of the maintenance and distribution of the
   PSL.
   3. Determine demand for domain relationship identification other than
   that provided by the PSL.
   4. Identify solutions to replace, extend, improve, or complement the
   functionality, maintenance, or distribution of the PSL according to
   perceived demands.

It seems to me that the primary problem statement is #3 on the list above.
Once that is established, then 1 and 2 are either irrelevant or important
and #4 becomes open to consideration.

I am slightly puzzled to not see any discussion of the question of
identifying ADMD boundaries since that question had come up in other
conversations.

The extensive conversation around public/private seems to be a concession
by approximation to the what people would really want to know about true
security boundaries (for some meaning of the words "security" and "true").

Looking forward to discussing these topics in Thursday's side meeting.

Cheers,
  Kurt Andersen

--089e0102fc4c0e9b9e0507afeb00
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 4, 2014 at 5:42 AM, Casey Deccio <span dir=3D"=
ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@deccio=
.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div><div><div><br></div>Please find attached a draft DBOUND problem state=
ment. . .<br></div></div></div></blockquote><div><br></div><div>Having had =
time to consider this write up (in the midst of all the IETF traffic), I ap=
preciate the work to clarify the scope and semantics, but it seems like the=
 problem summary puts the cart before the horse.<br><br></div><div>Taking t=
he liberty of numbering the existing list:<br><ol><li><span style=3D"font:1=
3px Arial">Evaluate the effectiveness of the current PSL at performing the =
functions within its scope.</span></li><li>
<span style=3D"font:13px Arial">Evaluate the effectiveness of the maintenan=
ce and distribution of the PSL.</span></li><li>
<span style=3D"font:13px Arial">Determine demand for domain relationship id=
entification other than that provided by the PSL.</span></li><li>
<span style=3D"font:13px Arial">Identify solutions to replace, extend, impr=
ove, or complement the functionality, maintenance, or distribution of the P=
SL according to perceived demands.</span></li></ol>
It seems to me that the primary problem statement is #3 on the list above. =
Once that is established, then 1 and 2 are either irrelevant or important a=
nd #4 becomes open to consideration.<br><br></div><div>I am slightly puzzle=
d to not see any discussion of the question of identifying ADMD boundaries =
since that question had come up in other conversations. <br><br></div><div>=
The extensive conversation around public/private seems to be a concession b=
y approximation to the what people would really want to know about true sec=
urity boundaries (for some meaning of the words &quot;security&quot; and &q=
uot;true&quot;).<br><br></div><div>Looking forward to discussing these topi=
cs in Thursday&#39;s side meeting.<br><br>Cheers,<br></div><div>=C2=A0 Kurt=
 Andersen<br></div></div><br></div></div>

--089e0102fc4c0e9b9e0507afeb00--


From nobody Wed Nov 12 16:16:07 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7CF1A0062 for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 16:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5maoohaBFNm for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 16:15:52 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7611B1A0059 for <dbound@ietf.org>; Wed, 12 Nov 2014 16:15:52 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id a13so3989135igq.17 for <dbound@ietf.org>; Wed, 12 Nov 2014 16:15:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ReNLsuKG/YpJ8dJ/EhlaBGz2Q7R36b3PbHNpHNx3i6I=; b=U1SS27ya97vSmiqg+d9N14F1BSqS+kv3F+RTu6dTqEwUno3rY7kCVP6KsKPVAsQVhN 56MKDJWznQIUvD3JvYJVwpB4s9mZdQCRNM6lH5MFjcsMnt+hMeekcrYE9Lr166zkLhV0 uUxQNOW1L48QQq1JANNwSB42XgV9Zs/jDQOpI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ReNLsuKG/YpJ8dJ/EhlaBGz2Q7R36b3PbHNpHNx3i6I=; b=DHZapYkhcYda5gdxiFhzuig7xqyDDPKPu6FNYOwgTAimufq7FNLXlpocLodpdz8WG/ v8IiGnQjeE3c7QXKRYSaA3dTnd9AgwxtfDEeDwUDfJH0+3Lah3JVU4j2Daxmyr373LKw TZw2JfXTKIUTwnoynovUUe8CoPUkkAOEYmkO66GAR7LQmW4+jzt+EuQzu0e8/18EkOlb tkrpN94p2RdawzdZqgSfh512yjJ0uj8DsOm7zS3LLQgzHVBZRP4fRiSEz1Tlj/Xj88qh Njw+1CIuw0aOUWlk4zgb08eXLmxS1/8Dgc+YsBVWQPwMKDVFm1MDRnWl028tIbWQFiVj MDLg==
X-Gm-Message-State: ALoCoQlZxBpg6Zmlu5N6GHnASpTpZfxCkelTUCkCf962cWnwQEWJ30+F4pzWmBz6Ja0ddxu48epy
MIME-Version: 1.0
X-Received: by 10.42.37.138 with SMTP id y10mr1909421icd.26.1415837751604; Wed, 12 Nov 2014 16:15:51 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Wed, 12 Nov 2014 16:15:51 -0800 (PST)
In-Reply-To: <54637CBE.4010908@mozilla.org>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <54591324.3040803@mozilla.org> <CAEKtLiTZziXQfFryHBn6=4+cGwbKyFFtk87Bv53mOM34Np3SRw@mail.gmail.com> <5459FA73.40208@mozilla.org> <CAEKtLiTOcUAzRx6TuJGKKWecGwW5PijPS2CCmZ5Qh61TCeW2_Q@mail.gmail.com> <54637CBE.4010908@mozilla.org>
Date: Wed, 12 Nov 2014 14:15:51 -1000
Message-ID: <CAEKtLiSsDaGe52gD4L+gcc=XFP7AFFKQsxYchu3ioDntS-90vg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Gervase Markham <gerv@mozilla.org>
Content-Type: multipart/alternative; boundary=90e6ba6e8fd43e95f70507b26ac6
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/trRlsAXwvX6e7le_cg3p2wNXqkQ
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 00:15:55 -0000

--90e6ba6e8fd43e95f70507b26ac6
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 12, 2014 at 5:29 AM, Gervase Markham <gerv@mozilla.org> wrote:

> "*.example" does indeed NOT imply "example", or any shorter rule in
> fact.


Yes, my quick test was faulty.  You are correct.

However, if the number of labels in the two rules you are looking
> at differs by only 1, what does it mean to list them both? In this case,
> when would the "example" rule ever get matched? Only by http://example/
> - but then such dotless names normally don't get checked against the PSL
> anyway, as it's assumed that they are intranet names.


In the contrived case, yes, but wildcards aren't always attached to TLDs,
which means that there are other cases besides dotless domains (for
example, *.sch.uk).

But more importantly, with HTTP cookies the PSL provides the ancestral
boundary for the cookie domain, which means that it really only matters
when the server name has at least one more label than the cookie domain
(i.e., a cookie with the same domain as the server name doesn't require the
PSL).  But more generally (i.e., outside of HTTP cookies) it might be
important to know that a domain name itself is public, regardless of
whether or not all its children are (e.g., due to a wildcard).

Best regards,
Casey

--90e6ba6e8fd43e95f70507b26ac6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 12, 2014 at 5:29 AM, Gervase Markham <span dir=
=3D"ltr">&lt;<a href=3D"mailto:gerv@mozilla.org" target=3D"_blank">gerv@moz=
illa.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&quot;*.exam=
ple&quot; does indeed NOT imply &quot;example&quot;, or any shorter rule in=
<br>
fact.</blockquote><div><br></div><div>Yes, my quick test was faulty.=C2=A0 =
You are correct.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"> However, if the number of labels in the two rules you are looking<br>
at differs by only 1, what does it mean to list them both? In this case,<br=
>
when would the &quot;example&quot; rule ever get matched? Only by <a href=
=3D"http://example/" target=3D"_blank">http://example/</a><br>
- but then such dotless names normally don&#39;t get checked against the PS=
L<br>
anyway, as it&#39;s assumed that they are intranet names.</blockquote><div>=
<br></div><div>In the contrived case, yes, but wildcards aren&#39;t always =
attached to TLDs, which means that there are other cases besides dotless do=
mains (for example, *.<a href=3D"http://sch.uk">sch.uk</a>).<br><br>But mor=
e importantly, with HTTP cookies the PSL provides the ancestral boundary fo=
r the cookie domain, which means that it really only matters when the serve=
r name has at least one more label than the cookie domain (i.e., a cookie w=
ith the same domain as the server name doesn&#39;t require the PSL).=C2=A0 =
But more generally (i.e., outside of HTTP cookies) it might be important to=
 know that a domain name itself is public, regardless of whether or not all=
 its children are (e.g., due to a wildcard).<br><br>Best regards,<br>Casey<=
br></div></div></div></div>

--90e6ba6e8fd43e95f70507b26ac6--


From nobody Wed Nov 12 17:06:00 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09341A03A4 for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 17:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuvHZ2I95bhy for <dbound@ietfa.amsl.com>; Wed, 12 Nov 2014 17:05:55 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DAA1A036A for <dbound@ietf.org>; Wed, 12 Nov 2014 17:05:55 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id rp18so14458066iec.23 for <dbound@ietf.org>; Wed, 12 Nov 2014 17:05:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+fZ8Aouyhh+1/CCsZzi7cHlTdZ8m55OPZ9UnCtBUDbo=; b=KoV2+X0/hEEonCOd4c0vQ4v7v/SjU4PCv5t9tH0GqdTyGgNLEcpSexQafW0uKPUkQV qCbitKBcBD54opdZB0D3NaPx8oP9QsrYS2gSeSLx1pdFy50DsbeOysSbO0HtBKeYy5rb ZL/UnsAVi+bMx/Gf7Dr4yReG9iGj/9LtPg0fc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+fZ8Aouyhh+1/CCsZzi7cHlTdZ8m55OPZ9UnCtBUDbo=; b=LghFQ6yYQFJErlG/tGZVxO0V+GOTyn3GqXTsRc2xFdrrlGpemPNouG2fjtQ2mzRX0G tV6GeA1WH8lfNvnqGSMAOuJkjh0TXeDJ2ZpKf/f1p+Nm78MSp2MGugNJIDXWywkOXw3r RkqdnvKBzmMneveLw/Qi+1wPLwIESKoYSBeXiF1Qfussl0DNwuHMWmx9q9kfYmbUr0GA wBJUzs5otE+mvBstLNMkIb4fNt14272tlo384fQ5cKc7cJ94azx6OoiSbahf+3zPnO84 gWT4WLjGeTZfrM1MhqlZEY4dOTxGRe1vI4ok6+wTS2bKQVfxtVGxbCw4ZvOmN3iLkTOt 2YGQ==
X-Gm-Message-State: ALoCoQmCvqujXgb0kyh9AjMFfHFUrzuetQ71kKkQx5w6zzmuneBMSrz8yl/FKry5ayUFZZ1q7HA0
MIME-Version: 1.0
X-Received: by 10.50.142.33 with SMTP id rt1mr3743039igb.12.1415840754643; Wed, 12 Nov 2014 17:05:54 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Wed, 12 Nov 2014 17:05:54 -0800 (PST)
In-Reply-To: <CABuGu1rkQfKQZia78QPkHEkC8DHczTaUuX5gm7yqFunhook7hw@mail.gmail.com>
References: <CAEKtLiSxWgt2NV2r1aYcLJLJqLcVS1-+u+cOFrnaH6Mph98SzA@mail.gmail.com> <CABuGu1rkQfKQZia78QPkHEkC8DHczTaUuX5gm7yqFunhook7hw@mail.gmail.com>
Date: Wed, 12 Nov 2014 15:05:54 -1000
Message-ID: <CAEKtLiQkfusCHK3MaQEnVL8CofXnp-JeoDW09QYrEev38fY7Gw@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Kurt Andersen <kboth@drkurt.com>
Content-Type: multipart/alternative; boundary=001a1130d17a3d50700507b31dff
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/qKfNFqIM7j3Ap4hEcFi9LBtTzvA
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 01:05:58 -0000

--001a1130d17a3d50700507b31dff
Content-Type: text/plain; charset=UTF-8

Hi Kurt,

On Wed, Nov 12, 2014 at 11:17 AM, Kurt Andersen <kboth@drkurt.com> wrote:

> On Tue, Nov 4, 2014 at 5:42 AM, Casey Deccio <casey@deccio.net> wrote:
>
>>
>> Please find attached a draft DBOUND problem statement. . .
>>
>
> Having had time to consider this write up (in the midst of all the IETF
> traffic), I appreciate the work to clarify the scope and semantics, but it
> seems like the problem summary puts the cart before the horse.
>
>
Thanks for the feedback.


> Taking the liberty of numbering the existing list:
>
>    1. Evaluate the effectiveness of the current PSL at performing the
>    functions within its scope.
>    2. Evaluate the effectiveness of the maintenance and distribution of
>    the PSL.
>    3. Determine demand for domain relationship identification other than
>    that provided by the PSL.
>    4. Identify solutions to replace, extend, improve, or complement the
>    functionality, maintenance, or distribution of the PSL according to
>    perceived demands.
>
> It seems to me that the primary problem statement is #3 on the list above.
> Once that is established, then 1 and 2 are either irrelevant or important
> and #4 becomes open to consideration.
>

The observation I have made as I've thought about the problem and examined
existing solutions is that public/private scope identification is a
significant contributor to the more general problem of domain association.
Certainly it is not the only aspect, and the solutions to public/private
scope identification do not generally apply to the domain association
problem.  However, because public/private scope identification has
significant existing demand within the more general problem, and there are
working solutions (e.g., the PSL), it seems fitting to give this aspect of
the problem appropriate attention.  This is especially the case because
there is relative simplicity, running code, and precedent, in terms of
install base.  Of course, that doesn't mean existing use cases and
solutions need to dictate future solutions, but they are certainly
considerations.

Therefore, I don't believe that #3 makes #1 and #2 irrelevant, as the #1 is
explicitly complementary to #3, and #2 is dependent on #1.  The intent to
#4 was to cover demands of both #1 and #3.


>
> I am slightly puzzled to not see any discussion of the question of
> identifying ADMD boundaries since that question had come up in other
> conversations.
>

Contributions are welcome :)


> The extensive conversation around public/private seems to be a concession
> by approximation to the what people would really want to know about true
> security boundaries (for some meaning of the words "security" and "true").
>

Again, I see it as a subset of the problem with significant current demand,
not a concession nor a general purpose solution.

Looking forward to discussing these topics in Thursday's side meeting.
>
>
Likewise.  Thanks again for the feedback.

Best regards,
Casey

--001a1130d17a3d50700507b31dff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Kurt,<br><div><br>On Wed, Nov 12, 2014 at 11:17 AM, Kur=
t Andersen <span dir=3D"ltr">&lt;<a href=3D"mailto:kboth@drkurt.com" target=
=3D"_blank">kboth@drkurt.com</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">On Tue, Nov 4, 2014 at 5:42 AM, Casey Deccio <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@deccio.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div>=
<div><br></div>Please find attached a draft DBOUND problem statement. . .<b=
r></div></div></div></blockquote><div><br></div><div>Having had time to con=
sider this write up (in the midst of all the IETF traffic), I appreciate th=
e work to clarify the scope and semantics, but it seems like the problem su=
mmary puts the cart before the horse.<br><br></div></div></div></div></bloc=
kquote><div><br></div><div>Thanks for the feedback.<br>=C2=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div></div><div>Taking the liberty of numbering the =
existing list:<span class=3D""><br><ol><li><span style=3D"font:13px Arial">=
Evaluate the effectiveness of the current PSL at performing the functions w=
ithin its scope.</span></li><li>
<span style=3D"font:13px Arial">Evaluate the effectiveness of the maintenan=
ce and distribution of the PSL.</span></li><li>
<span style=3D"font:13px Arial">Determine demand for domain relationship id=
entification other than that provided by the PSL.</span></li><li>
<span style=3D"font:13px Arial">Identify solutions to replace, extend, impr=
ove, or complement the functionality, maintenance, or distribution of the P=
SL according to perceived demands.</span></li></ol></span>
It seems to me that the primary problem statement is #3 on the list above. =
Once that is established, then 1 and 2 are either irrelevant or important a=
nd #4 becomes open to consideration.<br></div></div></div></div></blockquot=
e><div><br></div><div>The observation I have made as I&#39;ve thought about=
 the problem and examined existing solutions is that public/private scope i=
dentification is a significant contributor to the more general problem of d=
omain association.=C2=A0 Certainly it is not the only aspect, and the solut=
ions to public/private scope identification do not generally apply to the d=
omain association problem.=C2=A0 However, because public/private scope iden=
tification has significant existing demand within the more general problem,=
 and there are working solutions (e.g., the PSL), it seems fitting to give =
this aspect of the problem appropriate attention.=C2=A0 This is especially =
the case because there is relative simplicity, running code, and precedent,=
 in terms of install base.=C2=A0 Of course, that doesn&#39;t mean existing =
use cases and solutions need to dictate future solutions, but they are cert=
ainly considerations.<br><br>Therefore, I don&#39;t believe that #3 makes #=
1 and #2 irrelevant, as the #1 is explicitly complementary to #3, and #2 is=
 dependent on #1.=C2=A0 The intent to #4 was to cover demands of both #1 an=
d #3.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><=
div>I am slightly puzzled to not see any discussion of the question of iden=
tifying ADMD boundaries since that question had come up in other conversati=
ons. <br></div></div></div></div></blockquote><br></div><div class=3D"gmail=
_quote">Contributions are welcome :)<br></div><div class=3D"gmail_quote"><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>The extensive conversati=
on around public/private seems to be a concession by approximation to the w=
hat people would really want to know about true security boundaries (for so=
me meaning of the words &quot;security&quot; and &quot;true&quot;).<br></di=
v></div></div></div></blockquote><div><br></div><div>Again, I see it as a s=
ubset of the problem with significant current demand, not a concession nor =
a general purpose solution.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Lo=
oking forward to discussing these topics in Thursday&#39;s side meeting.<br=
><br></div></div></div></div></blockquote><div><br></div><div>Likewise.=C2=
=A0 Thanks again for the feedback.<br><br></div><div>Best regards,<br>Casey=
</div></div></div></div></div>

--001a1130d17a3d50700507b31dff--


From nobody Thu Nov 13 18:29:07 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE51A1AE2 for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 18:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuYt0_oxKgxP for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 18:28:59 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 8ACAC1A1B0C for <dbound@ietf.org>; Thu, 13 Nov 2014 18:28:56 -0800 (PST)
Received: (qmail 9237 invoked by uid 0); 14 Nov 2014 02:28:50 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 14 Nov 2014 02:28:50 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id FEUm1p00V2UhLwi01EUpql; Thu, 13 Nov 2014 19:28:49 -0700
X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=4BreF0GzsJ0A:10 a=QIhr-27iAAAA:8 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=t7-nprh3AAAA:8 a=W0ucIhDPAAAA:8 a=I0CVDw5ZAAAA:8 a=8pif782wAAAA:8 a=FDlX6vGbxIZsUqOzymMA:9 a=j6XoPyGOqW78HL2R:21 a=HqXcp7KCfTetc6oM:21 a=QEXdDO2ut3YA:10 a=KNk0FuK-Jv4A:10 a=e1i35A98MB8A:10 a=9jDjnVP-S04A:10 a=4rq7TwIXcRUA:10 a=lkR3YhDp1TUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=xiuFeujV0JXZPiPjPUhBzF+k2PmwXPc4QlB7w1T3n78=;  b=AYibDZliu8CG6YAb7IceO57VNJLNzRFI//BiQNO6Rj3K6nwMA9KEZQlnIY4SDbgx4NnsR2U4vIg9JdgQFmLNj28EueLviTKCqooByYoQ9k4VDzuSwtuol4vftQFf85JK;
Received: from [31.133.132.6] (port=55401) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Xp6cx-0003oH-4B for dbound@ietf.org; Thu, 13 Nov 2014 19:28:47 -0700
Message-ID: <546568D6.90802@KingsMountain.com>
Date: Thu, 13 Nov 2014 18:28:38 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.132.6 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/1C-TA1qRar2rwTGqDHKPsbEoUNw
Subject: [Dbound] HTTP cookie processing wrt "public suffixes"
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 02:29:06 -0000

This is a (draft) community-service posting: The purpose is to unambiguously 
state the specification of "cookie processing wrt public suffixes".

It is somewhat difficult to tease this out of the requisite specification(s) 
and associated documents, e.g., [RFC6265] and the Public Suffix List [PSL], 
and so here it is (corrections/comments welcome).

=JeffH
------
HTTP cookie processing wrt "public suffixes" aka "effective TLDs (eTLDs)"
v0.2

Contents:
   1. Terminology
   2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
   3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
   4. Excerpts from [RFC6265]
   5. References


1. Terminology:

Cookie - a unit of HTTP state management data, sent by the server to the UA 
as part of (some) HTTP responses. The UA returns cookie(s) to the server on 
all subsequent requests, modulo various rules (some of which are discussed 
herein, the full story is given by [RFC6265]).

eTLD / effective Top Level Domain - a term closely related to "public 
suffix". It is more general than the term "public suffix" -- i.e., because 
it implies that the domain in question ought to be treated effectively as a 
TLD, but it may actually not be an official TLD, nor might it allow for 
"public" subdomain registrations (as the term "public suffix" specifically 
implies).

Origin - {scheme, host, port} tuple of a webapp [RFC6454], also known as a 
Web Origin.

Public Suffix - A "public suffix" is a DNS domain [RFC1034] under which 
Internet users can directly register names [modulo some policies]. Some 
examples of public suffixes are .com, .co.uk and pvt.k12.ma.us [PSL]. Note 
however, this definition does not adequately address various subtleties in 
practice (hence, in part, the [DBOUND] effort). Also note that the term 
"effective TLD (eTLD)" is closely related, and that the domains listed in 
[PSL] are a superset of actual IANA-registered TLDs [IANA-TLDs].

single-label domain name - A DNS name consisting of a single label, e.g., 
"org", "net", "com". Note that on various networks, often in enterprise 
deployments, existence of "local" single-label domains is not uncommon, 
e.g., "corp", "www". See also eTLD and TLD.

subdomain - a child domain of some given domain [RFC1034]. E.g., 
foo.example.org is a subdomain of example.org.

superdomain - the parent domain of some given domain. E.g., example.org is 
the superdomain of foo.example.org.

TLD / Top-level Domain - TLDs are those single-label DNS domains directly 
under the global public DNS root [IANA-TLDs] [RFC1591]. However, not all 
single-label DNS names are globally-visible TLDs. See also single-label 
domain name.

UA / User Agent - A web browser, or other HTTP client implementation, that 
implements the HTTP State spec [RFC6265], i.e., accepts cookies sent by HTTP 
servers.

webapp - a web application, which has both a server-side and client-side 
instances. The client-side instances, which are emitted by the server-side 
over HTTP, are effectively mobile code (typically composed of 
HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have 
an origin derived from the server-side's URI. Note that this also 
encompasses "apps" that are not general purpose web browsers but that meet 
the definition of UA.



2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:

(a) A server-side webapp, whose origin's host component [RFC6454] (aka 
domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for 
its own domain name, or for superdomains -- unless the targeted superdomain 
is a eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only 
that host, or, to that host and all subdomains thereof (depending on 
server-specified particulars of the cookie itself).

(c) Conversely, a server-side webapp whose origin's host component IS 
denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar 
compendiums) can set cookies for itself (modulo UA configuration), but its 
subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD's cookies to subdomain servers.


3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs:

Excerpts from [RFC6265] expressing the specifics underlying the 
cookie-setting and -returning algorithms, and in which the effects of 
"public suffixes"/eTLDs are specified, are found in the section after this 
one. They are referred to (using an "S" prefix) in the following 
explanations of the algorithms summarized in the preceding section:

In terms of (a), a server that is NOT a eTLD doing cookie-setting: the 2nd 
portion of S 4.1.2.3 describes the cookie-setting semantics, step 5 of S 5.3 
handles cookie-setting attempts for "public suffixes", step 6 of S 5.3 
defines the determination of the cookie's applicable domain and its notation 
in the cookie's cookie store entry, e.g. setting the host-only-flag. The 
host-only-flag governs whether the cookie will be returned to the origin 
server only, or whether it will be returned to the origin server as well as 
its subdomains.

In terms of (b), a UA returning cookies to non-eTLD servers: S 5.4 governs 
the construction of the Cookie header for the HTTP request, which depends 
directly upon the cookie entry's host-only-flag, and the domain-match 
algorithm (S 5.1.3).


In terms of (c), a "public suffix"/eTLD webapp doing cookie-setting: the 2nd 
portion of S 4.1.2.3 describes again applies, and refers directly to S 5.3 
in this case. S 5.3 steps 5 and 6 apply and the path through them depends on 
whether the UA is config'd to reject "public suffixes" or not. If not, and 
the domain-attribute is empty, then in step 6 the cookie is stored in the 
cookie store with its host-only-flag set to true and its domain set to the 
canonicalized request-host.

In terms of (d), a UA returning cookies to a "public suffix"/eTLD server:
step 1 of S 5.4 will gather only such cookies and return them to ONLY the 
eTLD server, due to the manner that they were recorded in the cookie store.


4. Excerpts from [RFC6265]:

   [Note: I've included the hierarchy of [RFC6265] section titles in
    order to provide context.]

   4. Server Requirements
   4.1. Set-Cookie
   4.1.2. Semantics (Non-Normative)
   4.1.2.3. The Domain Attribute
   https://tools.ietf.org/html/rfc6265#section-4.1.2.3

    The Domain attribute specifies those hosts to which the cookie will
    be sent.  For example, if the value of the Domain attribute is
    "example.com", the user agent will include the cookie in the Cookie
    header when making HTTP requests to example.com, www.example.com, and
    www.corp.example.com. ... If the server omits the Domain attribute,
    the user agent will return the cookie only to the origin server.
    ...
    The user agent will reject cookies unless the Domain attribute
    specifies a scope for the cookie that would include the origin
    server.  For example, the user agent will accept a cookie with a
    Domain attribute of "example.com" or of "foo.example.com" from
    foo.example.com, but the user agent will not accept a cookie with a
    Domain attribute of "bar.example.com" or of "baz.foo.example.com".

    NOTE: For security reasons, many user agents are configured to reject
    Domain attributes that correspond to "public suffixes".  For example,
    some user agents will reject Domain attributes of "com" or "co.uk".
    (See Section 5.3 for more information.)
    ...

   5. User Agent Requirements
   5.1. Subcomponent Algorithms
   5.1.3. Domain Matching
   https://tools.ietf.org/html/rfc6265#section-5.1.3

    A string domain-matches a given domain string if at least one of the
    following conditions hold:

    o  The domain string and the string are identical.  (Note that both
       the domain string and the string will have been canonicalized to
       lower case at this point.)

    o  All of the following conditions hold:

       *  The domain string is a suffix of the string.

       *  The last character of the string that is not included in the
          domain string is a %x2E (".") character.

       *  The string is a host name (i.e., not an IP address).


   5.3. Storage Model
   https://tools.ietf.org/html/rfc6265#section-5.3
   ...
    5.   If the user agent is configured to reject "public suffixes" and
         the domain-attribute is a public suffix:

            If the domain-attribute is identical to the canonicalized
            request-host:

               Let the domain-attribute be the empty string.

            Otherwise:

               Ignore the cookie entirely and abort these steps.

            NOTE: A "public suffix" is a domain that is controlled by a
            public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
            This step is essential for preventing attacker.com from
            disrupting the integrity of example.com by setting a cookie
            with a Domain attribute of "com".  Unfortunately, the set of
            public suffixes (also known as "registry controlled domains")
            changes over time.  If feasible, user agents SHOULD use an
            up-to-date public suffix list, such as the one maintained by
            the Mozilla project at <http://publicsuffix.org/>.

    6.   If the domain-attribute is non-empty:

            If the canonicalized request-host does not domain-match the
            domain-attribute:

               Ignore the cookie entirely and abort these steps.

            Otherwise:

               Set the cookie's host-only-flag to false.

               Set the cookie's domain to the domain-attribute.

         Otherwise:

            Set the cookie's host-only-flag to true.

            Set the cookie's domain to the canonicalized request-host.
    ...

    5.4. The Cookie Header
    https://tools.ietf.org/html/rfc6265#section-5.4

    The user agent includes stored cookies in the Cookie HTTP request
    header.
    ...
    If the user agent does attach a Cookie header field to an HTTP
    request, the user agent MUST send the cookie-string (defined below)
    as the value of the header field.

    The user agent MUST use an algorithm equivalent to the following
    algorithm to compute the "cookie-string" from a cookie store and a
    request-uri:

    1.  Let cookie-list be the set of cookies from the cookie store that
        meets all of the following requirements:

        *  Either:

              The cookie's host-only-flag is true and the canonicalized
              request-host is identical to the cookie's domain.

           Or:

              The cookie's host-only-flag is false and the canonicalized
              request-host domain-matches the cookie's domain.

        *  The request-uri's path path-matches the cookie's path.

    ...

        *  If the cookie's http-only-flag is true, then exclude the
           cookie if the cookie-string is being generated for a "non-
           HTTP" API (as defined by the user agent).
    ...


5. References:

[DBOUND] https://www.ietf.org/mailman/listinfo/dbound

[IANA-TLDs] https://www.iana.org/domains/root/db

[PSL] Public Suffix List
       https://publicsuffix.org/

[RFC1034] DOMAIN NAMES - CONCEPTS AND FACILITIES
           https://tools.ietf.org/html/rfc1034

[RFC1591] Domain Name System Structure and Delegation
           http://tools.ietf.org/html/rfc1591
           see also: https://en.wikipedia.org/wiki/Top-level_domain

[RFC6265] HTTP State Management Mechanism
           https://tools.ietf.org/html/rfc6265

[RFC6454] The Web Origin Concept
           https://tools.ietf.org/html/rfc6454



end


From nobody Thu Nov 13 18:51:02 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A8C1A011E for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 18:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSyZabQNsJfN for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 18:50:58 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 984011A1B5F for <dbound@ietf.org>; Thu, 13 Nov 2014 18:50:58 -0800 (PST)
Received: (qmail 18169 invoked by uid 0); 14 Nov 2014 02:50:58 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 14 Nov 2014 02:50:57 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id FEqt1p00a2UhLwi01Eqwgk; Thu, 13 Nov 2014 19:50:56 -0700
X-Authority-Analysis: v=2.1 cv=W5+rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=4BreF0GzsJ0A:10 a=b4-Z_l_xAAAA:8 a=0F0jO4qMKsvzn7coDlkA:9 a=QEXdDO2ut3YA:10 a=8-R3CrZWaSUA:10 a=NTzQ_WnaG24A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=pFB5wIla9aOg6ASMHQ8ZB+4A9jPZy0XgepnyQzawITs=;  b=46xu0rnXOIfJw/u+y7tzAfD+0pJlUYLpCvJxOMW0Pr7caUSFhAgjflDqnk3d9DlBwUoFrA7pVmoIIGxkDdmbVNcAdcMtirgQ7s7x2AWBBk9zKM0WGPjnOqicY9aVPKah;
Received: from [31.133.132.6] (port=55505) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Xp6yM-00047d-Lp for dbound@ietf.org; Thu, 13 Nov 2014 19:50:54 -0700
Message-ID: <54656E05.7060608@KingsMountain.com>
Date: Thu, 13 Nov 2014 18:50:45 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.132.6 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/BJ2ot5D5hzN9VmnagXdlb2OQdvE
Subject: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 02:51:00 -0000

 > In my adventures I've come across a similar chunk of PSL-like
 > functionality, specifically in the land of PassiveDNS:
 >
 > https://archive.farsightsecurity.com/Passive_DNS/passive-dns-architecture.pdf

My understanding is that every CA has their own equivalent to the PSL 
(rather than relying directly on the PSL) and there's mumblings of similar 
lists in various other places.

and apparently there is skew between all these lists...

=JeffH



From nobody Thu Nov 13 19:29:14 2014
Return-Path: <bmanning@isi.edu>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16421A6EF1 for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 19:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level: 
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmqFjAljZx_x for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 19:28:59 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF37E1A03A5 for <dbound@ietf.org>; Thu, 13 Nov 2014 19:28:59 -0800 (PST)
Received: from [198.32.4.206] ([198.32.4.206]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id sAE3SHdi011924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Nov 2014 19:28:27 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=utf-8
From: manning bill <bmanning@isi.edu>
In-Reply-To: <54656E05.7060608@KingsMountain.com>
Date: Thu, 13 Nov 2014 19:28:17 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu>
References: <54656E05.7060608@KingsMountain.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>
X-Mailer: Apple Mail (2.1878.6)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/JSp1UBa2hsZWHwv71DzJqbqBUW8
Cc: dbound@ietf.org
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 03:29:06 -0000

Pumpkin Spiced Latte?
Pu=C5=9Fc=C4=83 Semiautomat=C4=83 cu Lunet=C4=83?
personal seat license?
Private Sewer Lateral?=20
Power Standards Lab?

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 13November2014Thursday, at 18:50, =3DJeffH =
<Jeff.Hodges@KingsMountain.com> wrote:

> > In my adventures I've come across a similar chunk of PSL-like
> > functionality, specifically in the land of PassiveDNS:
> >
> > =
https://archive.farsightsecurity.com/Passive_DNS/passive-dns-architecture.=
pdf
>=20
> My understanding is that every CA has their own equivalent to the PSL =
(rather than relying directly on the PSL) and there's mumblings of =
similar lists in various other places.
>=20
> and apparently there is skew between all these lists...
>=20
> =3DJeffH
>=20
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


From nobody Thu Nov 13 22:44:40 2014
Return-Path: <tim@eudaemon.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE221A6FFA for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 22:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-mYHX3gftrX for <dbound@ietfa.amsl.com>; Thu, 13 Nov 2014 22:44:37 -0800 (PST)
Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 423051A6FD0 for <Dbound@ietf.org>; Thu, 13 Nov 2014 22:44:37 -0800 (PST)
Received: from [10.190.6.92] (unknown [107.14.56.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 4F7C2CB46 for <Dbound@ietf.org>; Fri, 14 Nov 2014 01:44:34 -0500 (EST)
From: Tim Draegen <tim@eudaemon.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AEC423A-E8FF-4919-9A8B-74D78BC07745@eudaemon.net>
Date: Thu, 13 Nov 2014 20:44:34 -1000
To: Dbound@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/DZ3rrFDmFCiwgAE6ZMZ0NAiUJ10
Subject: [Dbound] DMARC science fiction use case
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 06:44:39 -0000

DMARC=E2=80=99s current use of the PSL is to determine the =
=E2=80=9COrganizational Domain=E2=80=9D.. for use when discovering DMARC =
policy records.  PSL works well enough for production environments in =
today=E2=80=99s world.

However, after hearing about cross-domain requirements of cookies and =
cross-domain security use cases in the browser, it strikes me that any =
functionality (policy authority?) that allows domains to be linked would =
be incredibly useful in the DMARC world, too.  DMARC=E2=80=99s =
requirement for Identifier Alignment between SPF-authenticated domain, =
DKIM d=3Ddomain, and a message=E2=80=99s From: domain could be relaxed =
to include domains that were somehow associated via a policy authority.

This capability would be *very* nice to have at hand.
=3D- Tim


From nobody Fri Nov 14 02:07:19 2014
Return-Path: <ogud@ogud.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C681A884D for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 02:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM4a4x4uZSdi for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 02:07:16 -0800 (PST)
Received: from smtp132.dfw.emailsrvr.com (smtp132.dfw.emailsrvr.com [67.192.241.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086561A8881 for <dbound@ietf.org>; Fri, 14 Nov 2014 02:07:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4AF4730025A for <dbound@ietf.org>; Fri, 14 Nov 2014 05:07:15 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B937F30024B for <dbound@ietf.org>; Fri, 14 Nov 2014 05:07:13 -0500 (EST)
X-Sender-Id: ogud@ogud.com
Received: from dhcp-93ac.meeting.ietf.org (dhcp-93ac.meeting.ietf.org [31.133.147.172]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Fri, 14 Nov 2014 10:07:15 GMT
From: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com>
Date: Fri, 14 Nov 2014 00:07:12 -1000
To: dbound@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/1Wx8CV-Hsm6pjuDMravmU6PIZYA
Subject: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 10:07:18 -0000

I hate the name PSL and this is just a copy of what I wrote into the =
jabber room today.=20

In general the appropriate DNS terms are =93Delegation domain=94 i.e. =
domain that gives out delegation domains=20
as that is quite broad and can cover almost any non-leaf domain I would =
suggest =93Open Delegation Domain=94.=20

For the inverse we do not have a good term I have been using =93Vanity =
Domain=94  or =93Closed Domain=94.=20

So PSL should be renamed to "ODD list=94

     Olafur


From nobody Fri Nov 14 06:13:45 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B9F1A0125 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 06:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXxLbWw44oHg for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 06:13:41 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0F01A00EF for <dbound@ietf.org>; Fri, 14 Nov 2014 06:13:41 -0800 (PST)
Received: from [86.172.148.252] (port=50935 helo=[192.168.1.72]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1XpHd5-0003qS-7J; Fri, 14 Nov 2014 14:13:39 +0000
Message-ID: <54660E0E.1080204@mozilla.org>
Date: Fri, 14 Nov 2014 14:13:34 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: Olafur Gudmundsson <ogud@ogud.com>, dbound@ietf.org
References: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com>
In-Reply-To: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/e5PLedEEVNxZyV4JclNwr3YCNV4
Subject: Re: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 14:13:43 -0000

On 14/11/14 10:07, Olafur Gudmundsson wrote:
> I hate the name PSL and this is just a copy of what I wrote into the jabber room today. 

Hey, at least we don't still call them "Effective TLDs". That name was
_not_ popular... :-)

Gerv


From nobody Fri Nov 14 06:17:09 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59D31A0121 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 06:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jZ0G58I6LRm for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 06:17:06 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687261A0120 for <dbound@ietf.org>; Fri, 14 Nov 2014 06:17:06 -0800 (PST)
Received: from [86.172.148.252] (port=51006 helo=[192.168.1.72]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1XpHgN-0000N0-Qf; Fri, 14 Nov 2014 14:17:04 +0000
Message-ID: <54660ED9.2030403@mozilla.org>
Date: Fri, 14 Nov 2014 14:16:57 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>, dbound@ietf.org
References: <54656E05.7060608@KingsMountain.com>
In-Reply-To: <54656E05.7060608@KingsMountain.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/B_QjDiig8JrvCpDvKhKEV58sE_w
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 14:17:08 -0000

On 14/11/14 02:50, =JeffH wrote:
> My understanding is that every CA has their own equivalent to the PSL
> (rather than relying directly on the PSL) and there's mumblings of
> similar lists in various other places.
> 
> and apparently there is skew between all these lists...

Well, the Baseline Requirements specifically mention the PSL, although
they don't mandate its use. However, this lack of mandate was to make it
open to the possibility that a standard solution may one day come along.

Gerv


From nobody Fri Nov 14 07:21:10 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221CE1A1A52 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 07:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b0P67PNALjC for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 07:21:07 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028E51A1A28 for <dbound@ietf.org>; Fri, 14 Nov 2014 07:21:07 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id u10so5498960lbd.31 for <dbound@ietf.org>; Fri, 14 Nov 2014 07:21:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jX71gZBOCWEDxwJOm3iW6DZVHgnmTpz27UjB5ylhiqc=; b=Ye9kwmgcx3txqD0mT5Bg99E1x3B/Jd3YVwrBnASerGPTOfdlIHj1pYWShkyIzVdhv3 e0xGDkdeeBrgHb4t/XVx+XO+A8BkKmnBD0yPBamOqfWcY7or9e19rAKUbXtkbWozKFce 3uILAciGxbTL+dCoXOU43exGvWXnP3FZLNZggTTwMZgSj1SPKYOfW6NSQMnUMMEL6RIu moDFDWlJIEdkmMi9E5qOPsJVfZRgUZmEROVKJYudBfMULIxyk0JqFNFOzb47hqK1QsFu mPH+lqTEVWSid2U4+rmGBHe35aFcmArHXQMJDb2bHIkPCmgcfrnyU2UbdeMsvW5prhjK BwqA==
X-Gm-Message-State: ALoCoQnQ8frcX21vAkYv/SiwQ+uamKvHyF2Y5ZrEB6i7scU/BQI1GJNQc7fRKlmXdZuIKU9erWgH
X-Received: by 10.112.57.227 with SMTP id l3mr8809237lbq.68.1415978465021; Fri, 14 Nov 2014 07:21:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.89.21 with HTTP; Fri, 14 Nov 2014 07:20:34 -0800 (PST)
In-Reply-To: <54660E0E.1080204@mozilla.org>
References: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com> <54660E0E.1080204@mozilla.org>
From: Jothan Frakes <jothan@jothan.com>
Date: Fri, 14 Nov 2014 07:20:34 -0800
Message-ID: <CAGrS0FLsVkBBnYtyF-M7QPrx2wtb=W_ddM2OwHLE5AUwraPrVQ@mail.gmail.com>
To: Gervase Markham <gerv@mozilla.org>
Content-Type: multipart/alternative; boundary=001a11345a006ae6330507d32dff
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/VDCj11LY7q74Vf2XpEdkRehknMY
Cc: Olafur Gudmundsson <ogud@ogud.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 15:21:09 -0000

--001a11345a006ae6330507d32dff
Content-Type: text/plain; charset=UTF-8

I was encouraged by the BoF dialog this time.

Folks get too caught up channeling their energy and passion towards
trashing the Mozilla PSL or the term "Effective" historically.

This time there was more actual constructive dialog around focusing on use
cases and what the problems are that were in such need of solving that PSLs
are created or used in the first place instead of focusing on the fact that
they are created, starting with the IANA PSL and building upon it.


Jothan Frakes
Tel: +1.206-355-0230


On Fri, Nov 14, 2014 at 6:13 AM, Gervase Markham <gerv@mozilla.org> wrote:

> On 14/11/14 10:07, Olafur Gudmundsson wrote:
> > I hate the name PSL and this is just a copy of what I wrote into the
> jabber room today.
>
> Hey, at least we don't still call them "Effective TLDs". That name was
> _not_ popular... :-)
>
> Gerv
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>

--001a11345a006ae6330507d32dff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was encouraged by the BoF dialog this time.<div><br></di=
v><div>Folks get too caught up channeling their energy and passion towards =
trashing the Mozilla PSL or the term &quot;Effective&quot; historically.</d=
iv><div><br></div><div>This time there was more actual constructive dialog =
around focusing on use cases and what the problems are that were in such ne=
ed of solving that PSLs are created or used in the first place instead of f=
ocusing on the fact that they are created, starting with the IANA PSL and b=
uilding upon it.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><d=
iv><div class=3D"gmail_signature"><div dir=3D"ltr"><br>Jothan Frakes<br>Tel=
: +1.206-355-0230<br><br></div></div></div>
<br><div class=3D"gmail_quote">On Fri, Nov 14, 2014 at 6:13 AM, Gervase Mar=
kham <span dir=3D"ltr">&lt;<a href=3D"mailto:gerv@mozilla.org" target=3D"_b=
lank">gerv@mozilla.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D"">On 14/11/14 10:07, Olafur Gudmundsson wrote:<br>
&gt; I hate the name PSL and this is just a copy of what I wrote into the j=
abber room today.<br>
<br>
</span>Hey, at least we don&#39;t still call them &quot;Effective TLDs&quot=
;. That name was<br>
_not_ popular... :-)<br>
<br>
Gerv<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Dbound mailing list<br>
<a href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br>
</div></div></blockquote></div><br></div>

--001a11345a006ae6330507d32dff--


From nobody Fri Nov 14 14:10:46 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CBB1ACF69 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJJ4nXgxIOyh for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:10:41 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835441ACF00 for <dbound@ietf.org>; Fri, 14 Nov 2014 14:10:41 -0800 (PST)
Received: from mx1.yitter.info (dhcp-bfe9.meeting.ietf.org [31.133.191.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BA9408A031 for <dbound@ietf.org>; Fri, 14 Nov 2014 22:10:39 +0000 (UTC)
Date: Fri, 14 Nov 2014 17:10:37 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141114221036.GC3345@mx1.yitter.info>
References: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/a2aR-toMkQZRxy7cP5ruQuny12k
Subject: Re: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 22:10:42 -0000

On Fri, Nov 14, 2014 at 12:07:12AM -1000, Olafur Gudmundsson wrote:

> In general the appropriate DNS terms are “Delegation domain” i.e. domain that gives out delegation domains 

No, that's not the appropriate DNS term.  Not all names that are
"public" perform delegation.  For instance, my employer does not add a
delegation below dyndns.org when you register example.dyndns.org.

Indeed, this is another instance of the same old mistake, which is
reading some relationship between DNS administrative details and
policy boundaries.  They are completely orthoganal to one another.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Fri Nov 14 14:18:36 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557B81ACFA1 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRTemtDNZkkg for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:18:23 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FBF1ACF6D for <dbound@ietf.org>; Fri, 14 Nov 2014 14:18:22 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAEMIHoE003304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Nov 2014 14:18:21 -0800
Message-ID: <54667F9F.9070309@dcrocker.net>
Date: Fri, 14 Nov 2014 14:18:07 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>, dbound@ietf.org
References: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com> <20141114221036.GC3345@mx1.yitter.info>
In-Reply-To: <20141114221036.GC3345@mx1.yitter.info>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 14 Nov 2014 14:18:21 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/wrgedX9I3C61t2beb-pZl_hbHfA
Subject: Re: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 22:18:25 -0000

On 11/14/2014 2:10 PM, Andrew Sullivan wrote:
> On Fri, Nov 14, 2014 at 12:07:12AM -1000, Olafur Gudmundsson wrote:
> 
>> In general the appropriate DNS terms are “Delegation domain” i.e. domain that gives out delegation domains 
> 
> No, that's not the appropriate DNS term.  Not all names that are
> "public" perform delegation.  For instance, my employer does not add a
> delegation below dyndns.org when you register example.dyndns.org.
> 
> Indeed, this is another instance of the same old mistake, which is
> reading some relationship between DNS administrative details and
> policy boundaries.  They are completely orthoganal to one another.


hmm.  a possibly pedagogical moment:

  So, 'delegation' refers to zone boundaries, which are a matter of
operational convenience, rather than (necessarily meaning)
administrative independence?

  I thought that DNSSec had succeeded in fully confounding the otherwise
clean point that zones were strictly operational and didn't imply
administrative relationship.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Nov 14 14:29:13 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E861A8909 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj32DPbJeQFX for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:29:07 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11A11AD038 for <dbound@ietf.org>; Fri, 14 Nov 2014 14:29:07 -0800 (PST)
Received: from mx1.yitter.info (dhcp-bfe9.meeting.ietf.org [31.133.191.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 00A688A031 for <dbound@ietf.org>; Fri, 14 Nov 2014 22:29:05 +0000 (UTC)
Date: Fri, 14 Nov 2014 17:29:04 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141114222903.GF3345@mx1.yitter.info>
References: <0C150CD7-F3B9-4B25-B36F-7FB698D11347@ogud.com> <20141114221036.GC3345@mx1.yitter.info> <54667F9F.9070309@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54667F9F.9070309@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ETVnu4w5PPN7WwKeCl_rt9XaN9w
Subject: Re: [Dbound] Names of domains
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 22:29:09 -0000

On Fri, Nov 14, 2014 at 02:18:07PM -0800, Dave Crocker wrote:
> 
>   So, 'delegation' refers to zone boundaries, which are a matter of
> operational convenience, rather than (necessarily meaning)
> administrative independence?

I'd prefer to say they're a matter of in-protocol distribution of
operations.  That does not tell you the relationsip between the two
sides of a zone cut.  To demonstrate this, issue the following two
queries:

dig -t SOA afilias-nst.info +noall +answer
dig -t SOA yyz1.afilias-nst.info +noall +answer

Those are both an apex, and they're plainly under the same
administrative control.  (I'm sure we can find more, but I happened to
know about these ones.)

>   I thought that DNSSec had succeeded in fully confounding the otherwise
> clean point that zones were strictly operational and didn't imply
> administrative relationship.

No, there was _always_ an administrative relationship, _of the DNS_.
You can't have a zone cut unless your parent agrees, because they have
to put NS records pointing to you in their zone.  But that does not
imply policy authority boundaries.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Fri Nov 14 14:58:12 2014
Return-Path: <Rick_Andrews@symantec.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0011AD1D5 for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVRWaAZsBblG for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 14:58:07 -0800 (PST)
Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123951A00BA for <dbound@ietf.org>; Fri, 14 Nov 2014 14:58:06 -0800 (PST)
X-AuditID: a66201d2-f79486d000005395-cf-546688fda7eb
Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 16.A9.21397.DF886645; Fri, 14 Nov 2014 22:58:05 +0000 (GMT)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from <Rick_Andrews@symantec.com>) id 1XpPoa-0006Ia-7P; Fri, 14 Nov 2014 17:58:04 -0500
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Fri, 14 Nov 2014 14:59:17 -0800
From: Rick Andrews <Rick_Andrews@symantec.com>
To: manning bill <bmanning@isi.edu>, =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Fri, 14 Nov 2014 14:58:02 -0800
Thread-Topic: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
Thread-Index: AdAAFYgQP/wWx5K3QNSE16JzMJO9TQASI0uw
Message-ID: <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu>
In-Reply-To: <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsWyLInRVfdvR1qIwdWjBhYHF4Za7Lp8jd3i x/aljA7MHkuW/GTy2P1+K4vHtTerWQKYo7hsUlJzMstSi/TtErgyVvztZCp4x1fRf/Y4SwPj Hr4uRk4OCQETif2LVjND2GISF+6tZ+ti5OIQEnjHKHH7xFdGkISQwCtGiWufFCHsVYwSW09L gNhsAnoSWx5fYQexRQS8JTpXbWUBsZkF1CV61m0Hs1kEVCWO3v4GZgsLpEhM+bOOEaI+VWL6 vJtAyziAbCOJzdOkQcK8AlESB6+eZodYlSjx9PQqsHJOAWuJv6deMoHYjEB3fj+1hglilbjE rSfzmSDuF5BYsuc81C+iEi8f/2OFqBeVuNO+nhFkFbOApsT6XfoQrYoSU7ofskOsFZQ4OfMJ C0SrpMTBFTdYJjBKzEKyYRZC9ywk3bOQdC9gZFnFKJOanGOYW5KYX1pSkFphYKRXXJmbCIzC ZL3k/NxNjJBIvLSD8f5h3UOMAhyMSjy8i8vTQoRYE8uAKg8xSnAwK4nwzqgFCvGmJFZWpRbl xxeV5qQWH2KU5mBREueNKkoKERJITyxJzU5NLUgtgskycXBKNTDax8lc1Ml7yKdxX9uxbI7z 4kOz5vVezzuydOW04qe33N79MjrHxdtw/5BixKnqTa2zzivOb2Na46WZMX+FWqjrEyW7BVE/ Hs6KflTRz3hz+zYrm5Sq5KWtmUGO1u91V/8I43u8P13EenrKKqftWmuVv275nq7BzjjxQ8ZK 1xsXbFhze1dmHw9TYinOSDTUYi4qTgQA0E/6hsACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4HXOj4ByHD4r0WecrJJ08xImNTU
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 22:58:12 -0000

UHVibGljIFN1ZmZpeCBMaXN0IChodHRwczovL3B1YmxpY3N1ZmZpeC5vcmcpDQoNCkplZmYsIFN5
bWFudGVjIGRvZXNuJ3QgaGF2ZSBpdHMgb3duIGVxdWl2YWxlbnQgb2YgdGhlIFBTTCAod2UgcmVs
eSBvbiBNb3ppbGxhJ3MpLCBhbmQgSSBiZWxpZXZlIG90aGVyIG1ham9yIENBcyByZWx5IG9uIGl0
IHRvbyBpbnN0ZWFkIG9mIGJ1aWxkaW5nIHRoZWlyIG93bi4NCg0KLVJpY2sNCgkNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5uaW5nIGJpbGwgW21haWx0bzpibWFubmluZ0Bp
c2kuZWR1XSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMywgMjAxNCA3OjI4IFBNDQpUbzog
PUplZmZIDQpDYzogZGJvdW5kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Rib3VuZF0gbXVsdGlw
bGUgUFNMLWVxdWl2YWxlbnRzIGV4aXN0ICh3YXM6IGFsZ29yaXRobWljIGJhY2tncm91bmQgbWF0
ZXJpYWwgZm9yIEJvRg0KDQpQdW1wa2luIFNwaWNlZCBMYXR0ZT8NClB1xZ9jxIMgU2VtaWF1dG9t
YXTEgyBjdSBMdW5ldMSDPw0KcGVyc29uYWwgc2VhdCBsaWNlbnNlPw0KUHJpdmF0ZSBTZXdlciBM
YXRlcmFsPyANClBvd2VyIFN0YW5kYXJkcyBMYWI/DQoNCi9iaWxsDQpQTyBCb3ggMTIzMTcNCk1h
cmluYSBkZWwgUmV5LCBDQSA5MDI5NQ0KMzEwLjMyMi44MTAyDQoNCk9uIDEzTm92ZW1iZXIyMDE0
VGh1cnNkYXksIGF0IDE4OjUwLCA9SmVmZkggPEplZmYuSG9kZ2VzQEtpbmdzTW91bnRhaW4uY29t
PiB3cm90ZToNCg0KPiA+IEluIG15IGFkdmVudHVyZXMgSSd2ZSBjb21lIGFjcm9zcyBhIHNpbWls
YXIgY2h1bmsgb2YgUFNMLWxpa2UgDQo+ID4gZnVuY3Rpb25hbGl0eSwgc3BlY2lmaWNhbGx5IGlu
IHRoZSBsYW5kIG9mIFBhc3NpdmVETlM6DQo+ID4NCj4gPiBodHRwczovL2FyY2hpdmUuZmFyc2ln
aHRzZWN1cml0eS5jb20vUGFzc2l2ZV9ETlMvcGFzc2l2ZS1kbnMtYXJjaGl0ZQ0KPiA+IGN0dXJl
LnBkZg0KPiANCj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGV2ZXJ5IENBIGhhcyB0aGVpciBv
d24gZXF1aXZhbGVudCB0byB0aGUgUFNMIChyYXRoZXIgdGhhbiByZWx5aW5nIGRpcmVjdGx5IG9u
IHRoZSBQU0wpIGFuZCB0aGVyZSdzIG11bWJsaW5ncyBvZiBzaW1pbGFyIGxpc3RzIGluIHZhcmlv
dXMgb3RoZXIgcGxhY2VzLg0KPiANCj4gYW5kIGFwcGFyZW50bHkgdGhlcmUgaXMgc2tldyBiZXR3
ZWVuIGFsbCB0aGVzZSBsaXN0cy4uLg0KPiANCj4gPUplZmZIDQo+IA0KPiANCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGJvdW5kIG1haWxpbmcg
bGlzdA0KPiBEYm91bmRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kYm91bmQNCg0KDQo=


From nobody Fri Nov 14 19:58:48 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864451A03AB for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 19:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.267
X-Spam-Level: 
X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6eI5BD3tQkK for <dbound@ietfa.amsl.com>; Fri, 14 Nov 2014 19:58:46 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id DBD2D1A006F for <dbound@ietf.org>; Fri, 14 Nov 2014 19:58:45 -0800 (PST)
Received: (qmail 26965 invoked by uid 0); 15 Nov 2014 03:58:45 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 15 Nov 2014 03:58:45 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with  id Flyc1p0082UhLwi01lyfaA; Sat, 15 Nov 2014 02:58:44 -0700
X-Authority-Analysis: v=2.1 cv=ON60g0qB c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=OhnQoqRkGF0A:10 a=NEAV23lmAAAA:8 a=Im5FKctxD99ukyFtVP0A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=DkwjzmKzC/sMloe3tz0meksMGKg0FDuGuWT0LNcLrDo=;  b=eDeQmD5XhdMnrYGiy1GnyJleJL5J3Jq8LtZ0OtRYuj4ELSxC6I+WZ8Yfs86nuQpyrSs9dqyvwP36/oyC0CcTNeyomiXlWDKgleSYKdAlFPjWfJjqumQiJPGVvq9T2TM2;
Received: from [64.134.239.108] (port=45602 helo=[192.168.6.242]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XpUVQ-0000pY-Nc for dbound@ietf.org; Fri, 14 Nov 2014 20:58:36 -0700
Message-ID: <5466CF62.3040106@KingsMountain.com>
Date: Fri, 14 Nov 2014 19:58:26 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 64.134.239.108 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/zp0QzFG7ejyiiPoRkHjLLDMYISY
Subject: [Dbound] initial cut at: draft-sullivan-dbound-problem-statement-00
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Nov 2014 03:58:47 -0000

Hi,

as discussed with Casey at the end of the dbound side meeting yesterday 
evening, I've taken draft-sullivan-domain-policy-authority-01.xml and 
renamed it, added John Levine & Casey as co-authors, cut out the solution 
approach, left in the intro & motivation, use cases, added Tim D's DMARC use 
case, and verified that it formats in Firefox using rfc2629.xslt. It is 
"rough" and can use some work :)

I didn't have time to fold in material from Casey's problem stmt doc; I 
looked at draft-levine-orgboundary-02 but wasn't sure there was anything in 
there appropriate to fold in that isn't already addressed.

I've created a new public repository at github for it..

   https://github.com/equalsJeffH/dbound

If you clone it to your local disk, and browse to that directory using 
firefox, and load "draft-sullivan-dbound-problem-statement-00.xml", it 
should render more-or-less formatted in the browser.

Andrew, John, Casey: please let me know your github account names and I can 
add you as collaborators on that repo.

HTH,

=JeffH


From nobody Sat Nov 15 10:19:02 2014
Return-Path: <noloader@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D731ACE0A for <dbound@ietfa.amsl.com>; Sat, 15 Nov 2014 10:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v89m7V-ufX_7 for <dbound@ietfa.amsl.com>; Sat, 15 Nov 2014 10:18:49 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBBD1ACE1B for <dbound@ietf.org>; Sat, 15 Nov 2014 10:18:49 -0800 (PST)
Received: by mail-ig0-f169.google.com with SMTP id hl2so108905igb.2 for <dbound@ietf.org>; Sat, 15 Nov 2014 10:18:48 -0800 (PST)
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-type; bh=xW8R5E7G5Bp07cR9PMOR1D0wekbBxlov+sPiQNlD5P4=; b=rr17QhqrFFYRQNYppm+NinLizOZn/TG0BZgYLUX5gBKp1qfk2RLihDQYGyZw78IoWn GlUnkn6zqeiWYThtEjKRuqqcSl8oELgy5ySkFOCOhTCU0vQTCrhC8iKOfBcaKNtgdsFB FqztDINAS4TZahDdazyp9eqLEFd1lfiLPSkS81xZeMyl9ObMqux9oZJskHD5b+rFGNf8 D5+2cVoh0BDSDzvfDqgJLTB2zZUDbpY4nd1As68hfAK9ESdBepnvMTYlpvSsmeoYaBEO uxG6FDl7ABC84y+D44ZYlluP9sKbf0c7T6A7/KTkQKoGLK6YihhWYtdUP1bC4b/U/ZAy 4wzQ==
MIME-Version: 1.0
X-Received: by 10.107.4.143 with SMTP id 137mr1617517ioe.88.1416075528904; Sat, 15 Nov 2014 10:18:48 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Sat, 15 Nov 2014 10:18:48 -0800 (PST)
In-Reply-To: <5466CF62.3040106@KingsMountain.com>
References: <5466CF62.3040106@KingsMountain.com>
Date: Sat, 15 Nov 2014 13:18:48 -0500
Message-ID: <CAH8yC8kfPHEo7=k1QQMw+ENDQphC7mfbSj4SsQCNEORXt5kzwA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/vvxWnT7hoh1aw64Hkk-D4t2rIQE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] initial cut at: draft-sullivan-dbound-problem-statement-00
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Nov 2014 18:18:54 -0000

Jeff,

Thanks for the work.

> approach, left in the intro & motivation, use cases, added Tim D's DMARC use
> case,

Its missing a use case: validating DNS names in X.509 certificates
(specifically, wildcarded names).

Its a different use case from HTTP cookies. Most folks don't build web
browsers. Many folks do use TLS for secure channels.

Jeff

On Fri, Nov 14, 2014 at 10:58 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> Hi,
>
> as discussed with Casey at the end of the dbound side meeting yesterday
> evening, I've taken draft-sullivan-domain-policy-authority-01.xml and
> renamed it, added John Levine & Casey as co-authors, cut out the solution
> approach, left in the intro & motivation, use cases, added Tim D's DMARC use
> case, and verified that it formats in Firefox using rfc2629.xslt. It is
> "rough" and can use some work :)
>
> I didn't have time to fold in material from Casey's problem stmt doc; I
> looked at draft-levine-orgboundary-02 but wasn't sure there was anything in
> there appropriate to fold in that isn't already addressed.
>
> I've created a new public repository at github for it..
>
>   https://github.com/equalsJeffH/dbound
>
> If you clone it to your local disk, and browse to that directory using
> firefox, and load "draft-sullivan-dbound-problem-statement-00.xml", it
> should render more-or-less formatted in the browser.
>
> Andrew, John, Casey: please let me know your github account names and I can
> add you as collaborators on that repo.
>


From nobody Mon Nov 17 01:26:30 2014
Return-Path: <rob.stradling@comodo.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02611A1A42 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 01:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0BblTQkMCFS for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 01:26:24 -0800 (PST)
Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 D63D81A1A3B for <dbound@ietf.org>; Mon, 17 Nov 2014 01:26:23 -0800 (PST)
Received: (qmail 23035 invoked by uid 1004); 17 Nov 2014 09:26:21 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 17 Nov 2014 09:26:21 +0000
Received: (qmail 27905 invoked by uid 1000); 17 Nov 2014 09:26:21 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 17 Nov 2014 09:26:21 +0000
Message-ID: <5469BF3D.7020300@comodo.com>
Date: Mon, 17 Nov 2014 09:26:21 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Rick Andrews <Rick_Andrews@symantec.com>, manning bill <bmanning@isi.edu>,  =JeffH <Jeff.Hodges@KingsMountain.com>
References: <54656E05.7060608@KingsMountain.com><44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/gn2nGOmDCiSb5KWIZxJlh4b0HIk
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 09:26:28 -0000

On 14/11/14 22:58, Rick Andrews wrote:
> Public Suffix List (https://publicsuffix.org)
>
> Jeff, Symantec doesn't have its own equivalent of the PSL (we rely on Mozilla's), and I believe other major CAs rely on it too instead of building their own.

Ditto for Comodo.

> -Rick
> 	
> -----Original Message-----
> From: manning bill [mailto:bmanning@isi.edu]
> Sent: Thursday, November 13, 2014 7:28 PM
> To: =JeffH
> Cc: dbound@ietf.org
> Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
>
> Pumpkin Spiced Latte?
> Puşc� Semiautomat� cu Lunet�?
> personal seat license?
> Private Sewer Lateral?
> Power Standards Lab?
>
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
> On 13November2014Thursday, at 18:50, =JeffH <Jeff.Hodges@KingsMountain.com> wrote:
>
>>> In my adventures I've come across a similar chunk of PSL-like
>>> functionality, specifically in the land of PassiveDNS:
>>>
>>> https://archive.farsightsecurity.com/Passive_DNS/passive-dns-archite
>>> cture.pdf
>>
>> My understanding is that every CA has their own equivalent to the PSL (rather than relying directly on the PSL) and there's mumblings of similar lists in various other places.
>>
>> and apparently there is skew between all these lists...
>>
>> =JeffH
>>
>>
>> _______________________________________________
>> Dbound mailing list
>> Dbound@ietf.org
>> https://www.ietf.org/mailman/listinfo/dbound
>
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Mon Nov 17 06:10:16 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034B51A1B26 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 06:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbbSEgpK7ksq for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 06:10:08 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27061A1B3F for <dbound@ietf.org>; Mon, 17 Nov 2014 06:10:07 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id rl12so1407035iec.30 for <dbound@ietf.org>; Mon, 17 Nov 2014 06:10:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZU+mnL0SyKidXvgx4cPdlxFBAkfe7rYPesvrSvipNPU=; b=ESBZdmpkDc5v+R8C2sWSx29xEZgt2CftJC74F1WfDIlcuNitK8t5uW/e8mep8wzvFr unf9x+bdz4aYzRnTWanSRCdvCcl9N/wA/vaQMUwyDeJ2v9gsl3KkxYNUzjKiFWFOcXd0 /t0l1UL7G1kwvcegZtLIAtqhctkOj7wUGEJCc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZU+mnL0SyKidXvgx4cPdlxFBAkfe7rYPesvrSvipNPU=; b=hjj3SpkBc+kzc+/+Hp9XmgD2RIcVac2FfND7BPfbCSrFkZPGVZu41UMmvHncLOMnJ6 noBEU53nq4cB/I2ku0wqM9/y6KG/PweK0VRRFC+kR08M5LxT0DbWJdIpFcmm7p6ZDA2L uou3aZVt2XijcQHafPtBWMSiu69KYcD1VA+a+8zZDuFnPqI/UBuooB1oR/HNkoNN9JKN jSJluMI9TjrGshtPIYpbiPSeHNlCrwh7UiZs5MPYzHjY4hyyJlXo8cCUA4GuxonNdF0y KjzTRhb5FUNY+RArcdh8s0X3SI6ZGK1QlkwxX7pHJvVu2PM+fIGYSzKjgB+Bx9OZNkWF yDIQ==
X-Gm-Message-State: ALoCoQlzOmfSA2WBiJIgovw10K3qm8Z85+gSPxMYjHeevQhKiU9pVtRhlf6cUXUq6hZJw2dTmicL
MIME-Version: 1.0
X-Received: by 10.43.78.196 with SMTP id zn4mr14793129icb.10.1416233406985; Mon, 17 Nov 2014 06:10:06 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 17 Nov 2014 06:10:06 -0800 (PST)
In-Reply-To: <5469BF3D.7020300@comodo.com>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5469BF3D.7020300@comodo.com>
Date: Mon, 17 Nov 2014 09:10:06 -0500
Message-ID: <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3b83424aac405080e89c2
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/qpd65VpU0fA9OgK-EFgfT9Qxw7w
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 14:10:14 -0000

--001a11c3b83424aac405080e89c2
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 4:26 AM, Rob Stradling <rob.stradling@comodo.com>
wrote:

> On 14/11/14 22:58, Rick Andrews wrote:
>
>> Public Suffix List (https://publicsuffix.org)
>>
>> Jeff, Symantec doesn't have its own equivalent of the PSL (we rely on
>> Mozilla's), and I believe other major CAs rely on it too instead of
>> building their own.
>>
>
> Ditto for Comodo.
>

Can anyone speak to the contrary, i.e., anecdotally identify consumption
and/or maintenance of a PSL-like resource other than the PSL?

Cheers,
Casey

--001a11c3b83424aac405080e89c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 17, 2014 at 4:26 AM, Rob Stradling <span dir=
=3D"ltr">&lt;<a href=3D"mailto:rob.stradling@comodo.com" target=3D"_blank">=
rob.stradling@comodo.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 14/11/=
14 22:58, Rick Andrews wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Public Suffix List (<a href=3D"https://publicsuffix.org" target=3D"_blank">=
https://publicsuffix.org</a>)<br>
<br>
Jeff, Symantec doesn&#39;t have its own equivalent of the PSL (we rely on M=
ozilla&#39;s), and I believe other major CAs rely on it too instead of buil=
ding their own.<br>
</blockquote>
<br></span>
Ditto for Comodo.<br></blockquote><div><br></div><div>Can anyone speak to t=
he contrary, i.e., anecdotally identify consumption and/or maintenance of a=
 PSL-like resource other than the PSL?<br><br></div><div>Cheers,<br></div><=
div>Casey<br></div></div></div></div>

--001a11c3b83424aac405080e89c2--


From nobody Mon Nov 17 06:13:51 2014
Return-Path: <gerv@mozilla.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDF31A1B5E for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 06:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2TDzZWcNNL4 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 06:13:47 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5860C1A1B5B for <dbound@ietf.org>; Mon, 17 Nov 2014 06:13:47 -0800 (PST)
Received: from [86.172.148.252] (port=52882 helo=[192.168.1.75]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gerv@mozilla.org>) id 1XqN3p-0000dX-4X; Mon, 17 Nov 2014 14:13:45 +0000
Message-ID: <546A0295.20309@mozilla.org>
Date: Mon, 17 Nov 2014 14:13:41 +0000
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: Casey Deccio <casey@deccio.net>, "dbound@ietf.org" <dbound@ietf.org>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5469BF3D.7020300@comodo.com> <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com>
In-Reply-To: <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com>
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/bUjCjAtHvmmj8Ev9iQ47VZ3-1bM
Subject: Re: [Dbound] multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 14:13:49 -0000

On 17/11/14 14:10, Casey Deccio wrote:
> Can anyone speak to the contrary, i.e., anecdotally identify consumption
> and/or maintenance of a PSL-like resource other than the PSL?

Now that IE has switched to using the PSL, I don't know of any others.

Gerv


From nobody Mon Nov 17 07:01:24 2014
Return-Path: <jeremy.rowley@digicert.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA731A6F5B for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 07:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.895
X-Spam-Level: 
X-Spam-Status: No, score=-4.895 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_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yzUrP5aY1MM for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 07:01:20 -0800 (PST)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624CF1A6F56 for <dbound@ietf.org>; Mon, 17 Nov 2014 07:01:20 -0800 (PST)
Message-ID: <546A0DBF.6080105@digicert.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1416236479; bh=W1AdKnnHjjPZA8yybehofQR9tDi1d7NKE1wJlvEg6Do=; h=Date:From:To:Subject:References:In-Reply-To; b=lCK11Un4WR0hOLZw21w33MlL4oI/flJ0KIwp4w0fku9S6qLKRUEBXB3fHJc1dESqU m3FHsD/HZhntYeI7jUA+XQ3LvbGimcW/NKvoYSjgAYKGi6xvzfOvjiFbN5kF7OVJiX Dl5Zp+fWdIbiqNYdBaEVKn2pa/rVvjt/FULbwpmE=
Date: Mon, 17 Nov 2014 08:01:19 -0700
From: Jeremy.Rowley <jeremy.rowley@digicert.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: <dbound@ietf.org>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5469BF3D.7020300@comodo.com> <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com>
In-Reply-To: <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000706060605060303090508"
X-Originating-IP: [67.166.110.179]
X-ClientProxiedBy: EX2.corp.digicert.com (10.12.0.6) To EX2.corp.digicert.com (10.12.0.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/2jBSeHnbj7k3joSwkbOx-nO0YAM
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 15:01:22 -0000

--------------000706060605060303090508
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit

There's also this one maintained by IANA:

http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Jeremy

On 11/17/2014 7:10 AM, Casey Deccio wrote:
> On Mon, Nov 17, 2014 at 4:26 AM, Rob Stradling 
> <rob.stradling@comodo.com <mailto:rob.stradling@comodo.com>> wrote:
>
>     On 14/11/14 22:58, Rick Andrews wrote:
>
>         Public Suffix List (https://publicsuffix.org)
>
>         Jeff, Symantec doesn't have its own equivalent of the PSL (we
>         rely on Mozilla's), and I believe other major CAs rely on it
>         too instead of building their own.
>
>
>     Ditto for Comodo.
>
>
> Can anyone speak to the contrary, i.e., anecdotally identify 
> consumption and/or maintenance of a PSL-like resource other than the PSL?
>
> Cheers,
> Casey
>
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


--------------000706060605060303090508
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    There's also this one maintained by IANA:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://data.iana.org/TLD/tlds-alpha-by-domain.txt">http://data.iana.org/TLD/tlds-alpha-by-domain.txt</a><br>
    <br>
    Jeremy<br>
    <br>
    <div class="moz-cite-prefix">On 11/17/2014 7:10 AM, Casey Deccio
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr">On Mon, Nov 17, 2014 at 4:26 AM, Rob Stradling <span
          dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>&gt;</span>
        wrote:<br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On
                14/11/14 22:58, Rick Andrews wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Public Suffix List (<a moz-do-not-send="true"
                    href="https://publicsuffix.org" target="_blank">https://publicsuffix.org</a>)<br>
                  <br>
                  Jeff, Symantec doesn't have its own equivalent of the
                  PSL (we rely on Mozilla's), and I believe other major
                  CAs rely on it too instead of building their own.<br>
                </blockquote>
                <br>
              </span>
              Ditto for Comodo.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Can anyone speak to the contrary, i.e., anecdotally
              identify consumption and/or maintenance of a PSL-like
              resource other than the PSL?<br>
              <br>
            </div>
            <div>Cheers,<br>
            </div>
            <div>Casey<br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Dbound mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dbound@ietf.org">Dbound@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/dbound">https://www.ietf.org/mailman/listinfo/dbound</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------000706060605060303090508--


From nobody Mon Nov 17 07:21:01 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8E1A6F6B for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 07:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vVMV34GY4pE for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 07:20:56 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69E91A6F67 for <dbound@ietf.org>; Mon, 17 Nov 2014 07:20:55 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id tp5so2473312ieb.23 for <dbound@ietf.org>; Mon, 17 Nov 2014 07:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RFoU4y76aAwRsxacFF2+7YWW7P7gfp8zme5rOUZBEmQ=; b=NxXDDZHmhPWWpTPjaVjGtbT9FY6Y7fsESrQ2Z7/yX0HOsLekTcJntQ53V+g5wCaznn RHBEeQpfwrytgLpZ886GamEqH7t52NIbtv6vbaZF7Psh2GYJbO+Qc9QAGbnJcSYjUThb Xqmxxc2CbVIg5FcBE/xKTi84G2YbacMUI1A1g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RFoU4y76aAwRsxacFF2+7YWW7P7gfp8zme5rOUZBEmQ=; b=ctVCtnZMp8WUiK2s8JOPWhIi81GQhBDacq/ncLQ/8T2gaE+Kgj44DqoGE9+6U4nSCH G2XPOJglaq2vFiYo+gS8xjGcfWMobbjtD5UVvAWg2C+iyTYMtRq0JL1miPWJkxVddCxg QmJx/b068F+nDOlvE03dtNsikdXVZFv6YA2pdcQ5ga2ZTzOfTihbXhTESBsXj43C2PqM K15Q3z1D+bJTrwqpYCQ5vx3+DkFpLSjAikuLXGpvnktn7xayJ0EsfyameBZjEnCTzEtC aWhTL0vVqVx/uJzXd4FmyN/m8WkJjYyzxmzsGdRKnlX7McuwZu+M9zanacbd72vWV2a/ qwdA==
X-Gm-Message-State: ALoCoQlMEHE8V0tC6kTHa5qehvQk3DmJd9zvWzTzi5JgFzn5KXNYNRf1L3qPVjayMbrGhY+qUrFa
MIME-Version: 1.0
X-Received: by 10.42.184.74 with SMTP id cj10mr2317249icb.80.1416237655017; Mon, 17 Nov 2014 07:20:55 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 17 Nov 2014 07:20:54 -0800 (PST)
In-Reply-To: <546A0DBF.6080105@digicert.com>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5469BF3D.7020300@comodo.com> <CAEKtLiT8=j4WYSdkoJt3twEkQRA8cKi1-43Q7two+CdUMjoT=g@mail.gmail.com> <546A0DBF.6080105@digicert.com>
Date: Mon, 17 Nov 2014 10:20:54 -0500
Message-ID: <CAEKtLiTp8AE1e0AZQMAhb7WURz0XZKvShsy4jpFjhWyA+Qq2QQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "Jeremy.Rowley" <jeremy.rowley@digicert.com>
Content-Type: multipart/alternative; boundary=20cf303f6ea858854d05080f8653
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/wNgaeO5_Yl5fiA3JwQfle9U83IA
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 15:20:57 -0000

--20cf303f6ea858854d05080f8653
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 10:01 AM, Jeremy.Rowley <jeremy.rowley@digicert.com>
wrote:

>  There's also this one maintained by IANA:
>
> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
>

Thanks, Jeremy.  I note that this particular listing doesn't tell us
anything more than what's in the root zone (it's exactly the list of TLDs
delegated in the root zone), so I might hesitate to call it PSL-like in
that sense.

Best regards,
Casey

--20cf303f6ea858854d05080f8653
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 17, 2014 at 10:01 AM, Jeremy.Rowley <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jeremy.rowley@digicert.com" target=3D"_blank=
">jeremy.rowley@digicert.com</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    There&#39;s also this one maintained by IANA:<br>
    <br>
    <a href=3D"http://data.iana.org/TLD/tlds-alpha-by-domain.txt" target=3D=
"_blank">http://data.iana.org/TLD/tlds-alpha-by-domain.txt</a><span class=
=3D"HOEnZb"><font color=3D"#888888"><br>
    </font></span></div></blockquote><div><br></div><div>Thanks, Jeremy.=C2=
=A0 I note that this particular listing doesn&#39;t tell us anything more t=
han what&#39;s in the root zone (it&#39;s exactly the list of TLDs delegate=
d in the root zone), so I might hesitate to call it PSL-like in that sense.=
<br><br></div><div>Best regards,<br></div><div>Casey <br></div></div></div>=
</div>

--20cf303f6ea858854d05080f8653--


From nobody Mon Nov 17 08:56:14 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6681A6F9B for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 08:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DROrwYSTK_VC for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 08:56:09 -0800 (PST)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508F11A6FDE for <dbound@ietf.org>; Mon, 17 Nov 2014 08:56:09 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id gf13so6690512lab.14 for <dbound@ietf.org>; Mon, 17 Nov 2014 08:56:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=4dCUcw8Vqa3ItQGi4NUOCVLQZ5/Ay5c6QsVzwZaR+08=; b=E31bYfT14xq0qoOn4dSzqK5LPgTrVi4/uNNMqhPbYNEaHbeGYjZOjBamGfEwMT6FWg ok56YFmpb/RK4OWBZ5nPw9EREarMgzp3Rj/AZQ+S5RbNaCVSo1sN6qdw2lkiBm1H1S6A cgzJHmtgga3kJGWt7hp9je1j9gIc031HKQ+RQDXtahRITVqbGztGS1VaDPaoqpzI/F8W UZSTF1WuS7ssvBj5Fz5gk+H9GEKo122XuwXqWlmL+ZIetjcbonNCUZjn08wBL56EEJB7 klYifwUuZkaiPAUCNepuH5CdxLChybRRU2YsPfrWmClvZ+AsyiPJSSeQtngXLxk+bUKF dLWA==
X-Gm-Message-State: ALoCoQlwTzpKMfsGjsQMLOnBy4OvpJOWUSkDkoLVwLLUJcAPM4J3IHJiALXkid/8XRKZ+FWlMn3Q
MIME-Version: 1.0
X-Received: by 10.112.137.234 with SMTP id ql10mr11747153lbb.91.1416243367515;  Mon, 17 Nov 2014 08:56:07 -0800 (PST)
Received: by 10.25.89.21 with HTTP; Mon, 17 Nov 2014 08:56:07 -0800 (PST)
Date: Mon, 17 Nov 2014 08:56:07 -0800
Message-ID: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com>
From: Jothan Frakes <jothan@jothan.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: multipart/alternative; boundary=089e01176f07d63272050810daff
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/U6h4Z9Mr7EQwMXvslpiPz9JQxLQ
Cc: "Jeremy.Rowley" <jeremy.rowley@digicert.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 16:56:12 -0000

--089e01176f07d63272050810daff
Content-Type: text/plain; charset=UTF-8

As Jeremy pointed out, the IANA TLD list is the main "PSL".

 I have raised this point before about the Mozilla maintained PSL being one
of the "Suffix Lists", the more notorious of them being the IANA PSL.

It gets down to splitting hairs over one's definition of "public".  Does
public mean "publicly available string resource", or does it mean "a list
of strings that are publicly accessible"?  If the former, then the IANA TLD
list is a PSL.

Even if the definition is the former, it does still qualify, but as a
subset of larger more detailed lists.  The IANA TLD list is really somewhat
of patient zero upon which most other lists are derived.

There is a demograph mix of use on these public suffix lists beyond
the browsers and certificate authorities.

Purely anecdotally, there is a '"TLD" or not' logic that developers and
integrators have created over the years, which the IANA PSL
gets incorporated into due to the efficiencies of not making network calls
(and having to depend upon them) to validate.

Later, as they notice there are strings that need more elegance to that
"TLD or not" logic, there is a branch out to either an internal proprietary
list or the list at publicsuffix.org once that developer or integrator
comes to the realization that it is necessary to also solve for the stub
zones at registries such as co.uk or com.au.

Historically, there have been other public lists, but many have fallen away
over time or have gone proprietary / private domain.

Yes, browsers use these, and yes, certificate authorities use these, and
those are slightly different use cases.  There are more.

We will see some more examples of use cases as we proceed, but I encourage
that the group wisdom on this dbound effort might keep in mind the
overarching use case of "TLD or not" logic, and benefit from the elements
of whatever PSL that can be leveraged and carried forward.

I have some asks out to some of the integrators and developers who have
reached out to me over the course of the past 8 or so years of my volunteer
time with Mozilla about their PSL effort to also describe use cases.

-jothan

On Monday, November 17, 2014, Casey Deccio <casey@deccio.net> wrote:

> On Mon, Nov 17, 2014 at 10:01 AM, Jeremy.Rowley <
> jeremy.rowley@digicert.com
> <javascript:_e(%7B%7D,'cvml','jeremy.rowley@digicert.com');>> wrote:
>
>>  There's also this one maintained by IANA:
>>
>> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
>>
>
> Thanks, Jeremy.  I note that this particular listing doesn't tell us
> anything more than what's in the root zone (it's exactly the list of TLDs
> delegated in the root zone), so I might hesitate to call it PSL-like in
> that sense.
>
> Best regards,
> Casey
>


-- 

Jothan Frakes
Tel: +1.206-355-0230

--089e01176f07d63272050810daff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>As Jeremy pointed out, the IANA TLD list is the main &quot;PSL&quot;.=
=C2=A0</div><div><br></div><div>=C2=A0I have raised this point before about=
 the Mozilla maintained=C2=A0PSL being one of the &quot;Suffix Lists&quot;,=
 the more notorious of them being the IANA PSL.</div><div><br></div><div>It=
 gets down to splitting hairs over one&#39;s definition of &quot;public&quo=
t;.=C2=A0 Does public mean &quot;publicly available string=C2=A0resource&qu=
ot;, or does it mean &quot;a list of strings that are publicly accessible&q=
uot;?=C2=A0 If the former, then the IANA TLD list is a PSL.</div><div><br><=
/div><div>Even if the definition is the former, it does still qualify, but =
as a subset of larger more detailed lists.=C2=A0 The IANA TLD list is reall=
y=C2=A0somewhat of patient zero upon which most other lists are derived.=C2=
=A0=C2=A0=C2=A0</div><div><br></div><div>There is a demograph mix of use on=
 these public suffix lists=C2=A0beyond the=C2=A0browsers and=C2=A0certifica=
te authorities.<br></div><div><br></div>Purely anecdotally, there is a &#39=
;&quot;TLD&quot; or not&#39;=C2=A0logic that developers and integrators hav=
e created over the years, which=C2=A0the IANA PSL gets=C2=A0incorporated in=
to due to the efficiencies of not making network calls (and having to depen=
d upon them)=C2=A0to validate.<div><br></div><div>Later,=C2=A0as they notic=
e there are strings that need more elegance to that &quot;TLD or not&quot; =
logic,=C2=A0there is a branch out to either an internal proprietary list or=
 the list at <a href=3D"http://publicsuffix.org">publicsuffix.org</a> once =
that developer or integrator comes to the realization that it is necessary =
to also solve for=C2=A0the stub zones at registries such as=C2=A0<a href=3D=
"http://co.uk">co.uk</a> or com.au.</div><div><br></div><div>Historically, =
there have been other public lists, but many=C2=A0have fallen away over tim=
e or have gone proprietary=C2=A0/ private=C2=A0domain.</div><div><br></div>=
<div>Yes, browsers=C2=A0use these, and yes, certificate authorities use the=
se, and those are slightly different use cases.=C2=A0 There are more.</div>=
<div><br></div><div> We will see some more examples of use cases as we proc=
eed,=C2=A0but I encourage that the group wisdom on this dbound effort might=
 keep in mind the overarching use case of &quot;TLD or not&quot; logic, and=
 benefit from the elements of whatever PSL that can be leveraged and=C2=A0c=
arried forward.</div><div><br></div><div>I have some asks out to some of th=
e integrators and developers who have reached out to me over the course of =
the past 8 or so years of my volunteer time with=C2=A0Mozilla about their P=
SL=C2=A0effort to also describe use cases.</div><div><br></div><div>-jothan=
<br><br>On Monday, November 17, 2014, Casey Deccio &lt;<a href=3D"mailto:ca=
sey@deccio.net">casey@deccio.net</a>&gt; wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">On Mon, Nov 17, 2014 at 10:01 AM, Jeremy.Rowley <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jere=
my.rowley@digicert.com&#39;);" target=3D"_blank">jeremy.rowley@digicert.com=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    There&#39;s also this one maintained by IANA:<br>
    <br>
    <a href=3D"http://data.iana.org/TLD/tlds-alpha-by-domain.txt" target=3D=
"_blank">http://data.iana.org/TLD/tlds-alpha-by-domain.txt</a><span><font c=
olor=3D"#888888"><br>
    </font></span></div></blockquote><div><br></div><div>Thanks, Jeremy.=C2=
=A0 I note that this particular listing doesn&#39;t tell us anything more t=
han what&#39;s in the root zone (it&#39;s exactly the list of TLDs delegate=
d in the root zone), so I might hesitate to call it PSL-like in that sense.=
<br><br></div><div>Best regards,<br></div><div>Casey <br></div></div></div>=
</div>
</blockquote></div><br><br>-- <br><div dir=3D"ltr"><br>Jothan Frakes<br>Tel=
: +1.206-355-0230<br><br></div><br>

--089e01176f07d63272050810daff--


From nobody Mon Nov 17 09:03:02 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E266D1A8035 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 09:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKs-xX0UpBSB for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 09:02:59 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F22E1A702B for <dbound@ietf.org>; Mon, 17 Nov 2014 09:02:51 -0800 (PST)
Received: from [10.154.185.122] (unknown [199.119.233.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 00FA48A035; Mon, 17 Nov 2014 17:02:49 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <5469BF3D.7020300@comodo.com>
Date: Mon, 17 Nov 2014 09:02:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4333A7B2-483F-424B-8ED2-77E0A5110373@anvilwalrusden.com>
References: <54656E05.7060608@KingsMountain.com> <44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu> <544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5469BF3D.7020300@comodo.com>
To: Rob Stradling <rob.stradling@comodo.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/kPK_xy0G0wiQ8X-yytEcaOcQa64
Cc: "dbound@ietf.org" <dbound@ietf.org>, =JeffH <Jeff.Hodges@KingsMountain.com>, Rick Andrews <Rick_Andrews@symantec.com>, manning bill <bmanning@isi.edu>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 17:03:01 -0000

This is interesting (good) news, because the claim about CAs maintaining a l=
ist of changes to the PSL that we added to the SOPA draft was inspired by a r=
emark Phill Hallam-Baker made at a mic. =20

A

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

> On Nov 17, 2014, at 1:26, Rob Stradling <rob.stradling@comodo.com> wrote:
>=20
>> On 14/11/14 22:58, Rick Andrews wrote:
>> Public Suffix List (https://publicsuffix.org)
>>=20
>> Jeff, Symantec doesn't have its own equivalent of the PSL (we rely on Moz=
illa's), and I believe other major CAs rely on it too instead of building th=
eir own.
>=20
> Ditto for Comodo.
>=20
>> -Rick
>>   =20
>> -----Original Message-----
>> From: manning bill [mailto:bmanning@isi.edu]
>> Sent: Thursday, November 13, 2014 7:28 PM
>> To: =3DJeffH
>> Cc: dbound@ietf.org
>> Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic ba=
ckground material for BoF
>>=20
>> Pumpkin Spiced Latte?
>> Pu=C5=9Fc=C4=83 Semiautomat=C4=83 cu Lunet=C4=83?
>> personal seat license?
>> Private Sewer Lateral?
>> Power Standards Lab?
>>=20
>> /bill
>> PO Box 12317
>> Marina del Rey, CA 90295
>> 310.322.8102
>>=20
>> On 13November2014Thursday, at 18:50, =3DJeffH <Jeff.Hodges@KingsMountain.=
com> wrote:
>>=20
>>>> In my adventures I've come across a similar chunk of PSL-like
>>>> functionality, specifically in the land of PassiveDNS:
>>>>=20
>>>> https://archive.farsightsecurity.com/Passive_DNS/passive-dns-archite
>>>> cture.pdf
>>>=20
>>> My understanding is that every CA has their own equivalent to the PSL (r=
ather than relying directly on the PSL) and there's mumblings of similar lis=
ts in various other places.
>>>=20
>>> and apparently there is skew between all these lists...
>>>=20
>>> =3DJeffH
>>>=20
>>>=20
>>> _______________________________________________
>>> Dbound mailing list
>>> Dbound@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dbound
>>=20
>>=20
>> _______________________________________________
>> Dbound mailing list
>> Dbound@ietf.org
>> https://www.ietf.org/mailman/listinfo/dbound
>=20
> --=20
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


From nobody Mon Nov 17 09:49:57 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1601A7004 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 09:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIzSXV14na57 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 09:49:53 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1A81A026A for <dbound@ietf.org>; Mon, 17 Nov 2014 09:49:53 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id rl12so1823464iec.5 for <dbound@ietf.org>; Mon, 17 Nov 2014 09:49:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U/LtWJ/1K38j2SZPFuQVKWfxii296yHcke3byXkKciM=; b=LM+ArmcZRHGHsNOm7r3fgOW00MdljgkUeZWQBbKECDPmduyM7f4YwOGlrwysHcOzdt d4sjCusao49w/+FkmYdT3p28Cjwn3pYGs+ggU6q7HvuP6/TswkRB+83TEvHljnbDBsUQ cFl18R+X0PKSXsY7MjmiHkwySiLIGrVZuYDII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U/LtWJ/1K38j2SZPFuQVKWfxii296yHcke3byXkKciM=; b=Lk2u81vrr3C9NPLAMTcVuemEiXScDogWhHZbAYh+l1PhzvfwXtTG6POUHsfzoFr0h/ NuHv+kZkvhE/R3glMvI/k8VoVtaAbNVCR7PSvMltDqH0YZB7+fuK/t6cf3+HtDiH+XMz OA1i/AopNn3NgmjKX15CddM9IKRgcxqamScC1320cvRlqqXe8Dl8a9FysQ9eHCqblqGJ cIsKUYDssXomkm8IHEhkAJ/imjzc6FEjhFDYdtUihv40u5feIPliGEh9pOfecPxnPtd7 lgPYmQ0Ls9NniY/SneWaRgIS+wWhpkFOJBo4Fv7nheTBbgkQATbJeQKMyDPb7+T+ZXNa A3uw==
X-Gm-Message-State: ALoCoQn+EnWsKOJfdEWNBqsRrHdw/JtCH5Ez4XatKZ0PPsn5/TXq0ESjtkj6l9Suqm1TNmuXZbBE
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr3792367ioo.73.1416246592345; Mon, 17 Nov 2014 09:49:52 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 17 Nov 2014 09:49:52 -0800 (PST)
In-Reply-To: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com>
Date: Mon, 17 Nov 2014 12:49:52 -0500
Message-ID: <CAEKtLiRw=2D+_ucttCfM=8T_PHMBRaCPhecoBe3jA0OG7FK43A@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Jothan Frakes <jothan@jothan.com>
Content-Type: multipart/alternative; boundary=001a113703b40d48400508119b40
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Ed2kztCogkMc-hizJWl9a-ZhKdI
Cc: "Jeremy.Rowley" <jeremy.rowley@digicert.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 17:49:55 -0000

--001a113703b40d48400508119b40
Content-Type: text/plain; charset=UTF-8

Hi Jothan,

On Mon, Nov 17, 2014 at 11:56 AM, Jothan Frakes <jothan@jothan.com> wrote:

> As Jeremy pointed out, the IANA TLD list is the main "PSL".
>
>  I have raised this point before about the Mozilla maintained PSL being
> one of the "Suffix Lists", the more notorious of them being the IANA PSL.
>
> It gets down to splitting hairs over one's definition of "public".  Does
> public mean "publicly available string resource", or does it mean "a list
> of strings that are publicly accessible"?  If the former, then the IANA TLD
> list is a PSL.
>

The IANA list of TLDs is just that--a complete list of TLDs delegated from
the IANA root.  It can be generated from the root zone with the following:

awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u > tlds.txt

If folks are using that list, it tells me several things:

1. They are interested in only top-level domains.
2. Unless their definition of "public" is limited to TLDs, then they are
getting an incomplete list.
3. Unless their definition of "public" considers that some TLDs might not
actually be public (not just speaking about HTTP cookies), their list might
include too much (the Mozilla PSL suffers from this as well).
4. This list can be derived from the root zone, either completely (e.g., by
the command above) or selectively (e.g., by issuing simple one-label
queries to the root servers).

That doesn't mean the list isn't useful to some, but simply that I don't
see it adding anything new to the root zone, either in terms of maintenance
or accessibility.  However, I'm interested to learn if I've missed
something and/or if folks are in fact using this list as some sort of PSL
equivalent/replacement.


> Even if the definition is the former, it does still qualify, but as a
> subset of larger more detailed lists.  The IANA TLD list is really somewhat
> of patient zero upon which most other lists are derived.
>

Let me be more clear about what I am asking.  DBOUND is working on a
problem statement, which, in part, should reflect demand and use cases for
learning relationships (or boundaries) between different domains--if it is
to be useful.  As there is some precedent, embodied in the Mozilla Public
Suffix List (PSL), it is useful to understand PSL use cases--not as the
only problem or solution, but as concrete examples of real use, both in
browsers and other applications.  The Mozilla PSL is not merely a list of
TLDs extracted from the root zone, but maintains nearly 7,000 entries,
delineating a "public" (for some definition of public) boundary in the DNS
namespace.  While it can likely be agreed that it is not a perfect or
comprehensive solution, nor does it address the general problem of domain
relationships--only boundaries--it is well used, and represents a
non-trivial compilation and effort.

Now my question: it has been suggested that there are other lists being
maintained and consumed in *like* manner.  Can some lists and use cases be
positively identified?


>
> There is a demograph mix of use on these public suffix lists beyond
> the browsers and certificate authorities.
>

That's what we're looking to understand.


>
> Purely anecdotally, there is a '"TLD" or not' logic that developers and
> integrators have created over the years, which the IANA PSL
> gets incorporated into due to the efficiencies of not making network calls
> (and having to depend upon them) to validate.


TLD (i.e., existing single-label DNS name) or not can be done online or
offline, using only the root zone as the ultimate source.


> ...
>
> Historically, there have been other public lists, but many have fallen
> away over time or have gone proprietary / private domain.
>
> Yes, browsers use these, and yes, certificate authorities use these, and
> those are slightly different use cases.  There are more.
>

Lists and use cases - that's what we're looking for.


> ...
> I have some asks out to some of the integrators and developers who have
> reached out to me over the course of the past 8 or so years of my volunteer
> time with Mozilla about their PSL effort to also describe use cases.
>

Thanks!

Best regards,
Casey

--001a113703b40d48400508119b40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jothan,<br><div><br>On Mon, Nov 17, 2014 at 11:56 AM, J=
othan Frakes <span dir=3D"ltr">&lt;<a href=3D"mailto:jothan@jothan.com" tar=
get=3D"_blank">jothan@jothan.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div>As Jeremy pointed out, the IANA TLD list is the main &quot=
;PSL&quot;.=C2=A0</div><div><br></div><div>=C2=A0I have raised this point b=
efore about the Mozilla maintained=C2=A0PSL being one of the &quot;Suffix L=
ists&quot;, the more notorious of them being the IANA PSL.</div><div><br></=
div><div>It gets down to splitting hairs over one&#39;s definition of &quot=
;public&quot;.=C2=A0 Does public mean &quot;publicly available string=C2=A0=
resource&quot;, or does it mean &quot;a list of strings that are publicly a=
ccessible&quot;?=C2=A0 If the former, then the IANA TLD list is a PSL.</div=
></blockquote><div><br></div><div>The IANA list of TLDs is just that--a com=
plete list of TLDs delegated from the IANA root.=C2=A0 It can be generated =
from the root zone with the following:<br><br>awk &#39;$4 =3D=3D &quot;NS&q=
uot; { print $1 }&#39; root.zone | sed &#39;s/\.$//&#39; | sort -u &gt; tld=
s.txt<br><br></div><div>If folks are using that list, it tells me several t=
hings:<br><br></div><div>1. They are interested in only top-level domains.<=
br>2. Unless their definition of &quot;public&quot; is limited to TLDs, the=
n they are getting an incomplete list.<br></div><div>3. Unless their defini=
tion of &quot;public&quot; considers that some TLDs might not actually be p=
ublic (not just speaking about HTTP cookies), their list might include too =
much (the Mozilla PSL suffers from this as well).<br></div><div>4. This lis=
t can be derived from the root zone, either completely (e.g., by the comman=
d above) or selectively (e.g., by issuing simple one-label queries to the r=
oot servers).<br><br></div><div>That doesn&#39;t mean the list isn&#39;t us=
eful to some, but simply that I don&#39;t see it adding anything new to the=
 root zone, either in terms of maintenance or accessibility.=C2=A0 However,=
 I&#39;m interested to learn if I&#39;ve missed something and/or if folks a=
re in fact using this list as some sort of PSL equivalent/replacement.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><=
div>Even if the definition is the former, it does still qualify, but as a s=
ubset of larger more detailed lists.=C2=A0 The IANA TLD list is really=C2=
=A0somewhat of patient zero upon which most other lists are derived.=C2=A0=
=C2=A0=C2=A0</div></blockquote><div><br></div><div>Let me be more clear abo=
ut what I am asking.=C2=A0 DBOUND is working on a problem statement, which,=
 in part, should reflect demand and use cases for learning relationships (o=
r boundaries) between different domains--if it is to be useful.=C2=A0 As th=
ere is some precedent, embodied in the Mozilla Public Suffix List (PSL), it=
 is useful to understand PSL use cases--not as the only problem or solution=
, but as concrete examples of real use, both in browsers and other applicat=
ions.=C2=A0 The Mozilla PSL is not merely a list of TLDs extracted from the=
 root zone, but maintains nearly 7,000 entries, delineating a &quot;public&=
quot; (for some definition of public) boundary in the DNS namespace.=C2=A0 =
While it can likely be agreed that it is not a perfect or comprehensive sol=
ution, nor does it address the general problem of domain relationships--onl=
y boundaries--it is well used, and represents a non-trivial compilation and=
 effort.<br><br>Now my question: it has been suggested that there are other=
 lists being maintained and consumed in *like* manner.=C2=A0 Can some lists=
 and use cases be positively identified?<br>=C2=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div><br></div><div>There is a demograph=
 mix of use on these public suffix lists=C2=A0beyond the=C2=A0browsers and=
=C2=A0certificate authorities.<br></div></blockquote><div><br></div><div>Th=
at&#39;s what we&#39;re looking to understand.<br>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div></div><div><br></div>Purely a=
necdotally, there is a &#39;&quot;TLD&quot; or not&#39;=C2=A0logic that dev=
elopers and integrators have created over the years, which=C2=A0the IANA PS=
L gets=C2=A0incorporated into due to the efficiencies of not making network=
 calls (and having to depend upon them)=C2=A0to validate.</blockquote><br><=
/div><div class=3D"gmail_quote">TLD (i.e., existing single-label DNS name) =
or not can be done online or offline, using only the root zone as the ultim=
ate source.<br></div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div>...</div><div><br></div><div>H=
istorically, there have been other public lists, but many=C2=A0have fallen =
away over time or have gone proprietary=C2=A0/ private=C2=A0domain.</div><d=
iv><br></div><div>Yes, browsers=C2=A0use these, and yes, certificate author=
ities use these, and those are slightly different use cases.=C2=A0 There ar=
e more.</div></blockquote><div><br></div><div>Lists and use cases - that&#3=
9;s what we&#39;re looking for.=C2=A0</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div>...<br></div><div>I have some asks =
out to some of the integrators and developers who have reached out to me ov=
er the course of the past 8 or so years of my volunteer time with=C2=A0Mozi=
lla about their PSL=C2=A0effort to also describe use cases.</div></blockquo=
te><div><br></div><div>Thanks!<br><br></div><div>Best regards,<br></div><di=
v>Casey<br></div></div></div></div></div>

--001a113703b40d48400508119b40--


From nobody Mon Nov 17 10:56:32 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F821A882A for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 10:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level: 
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyUS2rKh6Bnx for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 10:56:29 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A6D1A87BE for <dbound@ietf.org>; Mon, 17 Nov 2014 10:56:29 -0800 (PST)
Received: (qmail 93345 invoked from network); 17 Nov 2014 18:56:28 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Nov 2014 18:56:28 -0000
Date: 17 Nov 2014 18:56:06 -0000
Message-ID: <20141117185606.17010.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <546A0DBF.6080105@digicert.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/c9XUJO8d0U3ep8jrfc2hxLXoyKE
Cc: jeremy.rowley@digicert.com
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 18:56:31 -0000

In article <546A0DBF.6080105@digicert.com> you write:
>There's also this one maintained by IANA:
>
>http://data.iana.org/TLD/tlds-alpha-by-domain.txt

That's not a PSL, that's the authoritative list of actual TLDs.  If
all of the authority cuts were directly below the TLD, we wouldn't
need to have this discussion.

R's,
John


From nobody Mon Nov 17 11:02:54 2014
Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E911A19FC for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.333
X-Spam-Level: 
X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDxOLCT6vAyc for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:02:43 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 4EEA01A8902 for <dbound@ietf.org>; Mon, 17 Nov 2014 11:02:43 -0800 (PST)
Received: (qmail 12677 invoked by uid 0); 17 Nov 2014 19:02:43 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 17 Nov 2014 19:02:43 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with  id Gj2G1p0062UhLwi01j2K41; Mon, 17 Nov 2014 12:02:19 -0700
X-Authority-Analysis: v=2.1 cv=W++rC3mk c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=SojtekhEa5wA:10 a=WcQ5s9TIAAAA:8 a=I0CVDw5ZAAAA:8 a=Zqwm4H_rlODowGIPS7AA:9 a=QEXdDO2ut3YA:10 a=ykTbKJCSyyMA:10 a=8Q2WY7vDcykA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=SslifjAcmXStNx81kFrGwrpjYzwaKwd9dQ/e+e4QCm8=;  b=fpKr+yLJzWAKf7yDpkb+xnSqGNuchudare/tqCbRw35cK8wQ1RhdjBWShbMvX3pu5k872rikR1RLjZneOwSUsZgvdN6Aqxc7tp83ZLsmaDKJsuqLxVtir8Yqi5YRfEv5;
Received: from [216.113.160.66] (port=64003 helo=[10.244.137.167]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1XqRZ1-0005G8-R0 for dbound@ietf.org; Mon, 17 Nov 2014 12:02:15 -0700
Message-ID: <546A4636.4050502@KingsMountain.com>
Date: Mon, 17 Nov 2014 11:02:14 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dbound@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.160.66 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/P0dIZZg363ftSafE6X6vJJ0FIh0
Subject: [Dbound] commands to get TLD list (was: multiple PSL-equivalents exist..
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 19:02:52 -0000

Casey supplied..

 > awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u > tlds.txt

cool, thx. tho one needs to do this first to get the root.zone file..

wget http://www.internic.net/domain/root.zone
awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u > tlds.txt

[see also: https://www.iana.org/domains/root/files ]


results:

 > head -20 tlds.txt

abogado
ac
academy
accountants
active
actor
ad
ae
aero
af
ag
agency
ai
airforce
al
allfinanz
alsace
am
an
...



From nobody Mon Nov 17 11:05:15 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DA81A88FF for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level: 
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofz6CynK8sHv for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:05:10 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D5D1A890A for <dbound@ietf.org>; Mon, 17 Nov 2014 11:05:09 -0800 (PST)
Received: (qmail 94483 invoked from network); 17 Nov 2014 19:05:09 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Nov 2014 19:05:09 -0000
Date: 17 Nov 2014 19:04:47 -0000
Message-ID: <20141117190447.17052.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Z-A70qCUJ7vVQwuUoC96iCW44xs
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 19:05:12 -0000

>It gets down to splitting hairs over one's definition of "public". ...

At our meeting in Honolulu, it seemed pretty clear to me that the
distinction between public and private isn't useful here.  What is
useful is the boundaries between one authority (for a suitable and
probably painful to tease out definition of "authority") and another.

R's,
John


From nobody Mon Nov 17 11:27:50 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249541A8A62 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICFX0Ikw-RfO for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:27:44 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575121A8A4D for <dbound@ietf.org>; Mon, 17 Nov 2014 11:27:43 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id tp5so3075793ieb.37 for <dbound@ietf.org>; Mon, 17 Nov 2014 11:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AZa8RKBkrUn20oBAkyty85+v3/BcZs3vp0IJ9+sfHbc=; b=OAV5VlwWbdoeN96D2YptcW3zbwbY9VfaIgCpF79IlgyMKLkj5Sgp748U06jNXL8rnC UpFz2KgmcR00+d2cDyoFw8m+iV6zKS6vo/6VaJocJSt7DeEPqtrXTe3Pg4bKSkLO3xWi UOxo4VXeXRm7h2G55yaglSQrYDeJPsFjV9XnQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AZa8RKBkrUn20oBAkyty85+v3/BcZs3vp0IJ9+sfHbc=; b=gmyc5K54cAS+1SRP21ysWEojlRRAFoYoLbQZx3T77naDidGIv/hkSJnZtnAG+1Mi2L bOx2l0BwjcW5E3X00VQs0ehzcS++9/Q91SVkNJ4rJPD96+34k+RQTUMM+C4voXwLIsJX u4Qj6p3bdp48Q5l6IJu0TwYIvDX8PMHmv+ARNg4Sd2Y92gpk/VLPlp0h9An24mHwnugX lW0sq2IyYDIe64BE32XEpXLgTu2eAlJOB+ZJxu5tlaQGZIyY4izo7kYmm1F9st04BRq6 plFGvM8A82pmPlx9ApxxyEeYeClWbyZ9MJxjm5IFtC7Ob8yklDDyIZiJDkwSv7w22wcJ ahaQ==
X-Gm-Message-State: ALoCoQmNgMfcS2WJK1DG2/IoVs7hjIcWp9/gmocsl916Lhj5qB5TVte/XionB/itZdEz1uXrwstO
MIME-Version: 1.0
X-Received: by 10.50.43.135 with SMTP id w7mr28236134igl.0.1416252462245; Mon, 17 Nov 2014 11:27:42 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Mon, 17 Nov 2014 11:27:42 -0800 (PST)
In-Reply-To: <20141117190447.17052.qmail@ary.lan>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan>
Date: Mon, 17 Nov 2014 14:27:42 -0500
Message-ID: <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/mixed; boundary=089e01228114ecd82e050812f81d
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4BWkdE1Vk6W1aGUO8LFfyrPhPeQ
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 19:27:46 -0000

--089e01228114ecd82e050812f81d
Content-Type: multipart/alternative; boundary=089e01228114ecd82b050812f81b

--089e01228114ecd82b050812f81b
Content-Type: text/plain; charset=UTF-8

Hi John,

On Mon, Nov 17, 2014 at 2:04 PM, John Levine <johnl@taugh.com> wrote:

> >It gets down to splitting hairs over one's definition of "public". ...
>
> At our meeting in Honolulu, it seemed pretty clear to me that the
> distinction between public and private isn't useful here.  What is
> useful is the boundaries between one authority (for a suitable and
> probably painful to tease out definition of "authority") and another.
>
>
I realize that there were different opinions on this, but that the
distinction is not useful was not clear to me at all in the meeting.
Whether or not public and private are well defined and whether or not they
are even the right terms for use in that particular boundary might be in
question (both were raised during the side meeting in Honolulu).  But I
disagree on your assessment of the utility of the boundary, and dismissing
them early on as part of the background and problem statement is
premature.  As far as I have observed, no one considers such boundaries or
the related solutions (e.g., the PSL) comprehensive, but it obviously has
been useful in solving some subset of the problem with existing means.

That being said, I had proposed that the problem of identifying domain
relationships and boundaries was broken up into several areas, one of which
was "cross-scope" (i.e., public/private), which I believe is the part
directly addressed by the Mozilla PSL.  Independent of whether the public
boundaries are drawn accurately by the Mozilla (and I'm not suggesting one
way or the other), I am curious what the demand for identifing cross-scope
vs. other relationships is in application use.  I've attached a problem
breakdown treemap, where aggregate area represents demand/use cases.  In my
opinion, making the problem demand tree map more proportional to the demand
and use cases can really help us understand what we're trying to solve.  We
have lots of conjecture (including my own), but we need real data points.
Otherwise we will get caught up in either justifying proposed solutions or
arguing philosophy.

Best regards,
Casey

--089e01228114ecd82b050812f81b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi John,<br><div><br>On Mon, Nov 17, 2014 at 2:04 PM, John=
 Levine <span dir=3D"ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"=
_blank">johnl@taugh.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;It gets down=
 to splitting hairs over one&#39;s definition of &quot;public&quot;. ...<br=
>
<br>
At our meeting in Honolulu, it seemed pretty clear to me that the<br>
distinction between public and private isn&#39;t useful here.=C2=A0 What is=
<br>
useful is the boundaries between one authority (for a suitable and<br>
probably painful to tease out definition of &quot;authority&quot;) and anot=
her.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div>I realize that there were different opinions on this, but that the=
 distinction is not useful was not clear to me at all in the meeting.=C2=A0=
 Whether or not public and private are well defined and whether or not they=
 are even the right terms for use in that particular boundary might be in q=
uestion (both were raised during the side meeting in Honolulu).=C2=A0 But I=
 disagree on your assessment of the utility of the boundary, and dismissing=
 them early on as part of the background and problem statement is premature=
.=C2=A0 As far as I have observed, no one considers such boundaries or the =
related solutions (e.g., the PSL) comprehensive, but it obviously has been =
useful in solving some subset of the problem with existing means.<br><br>Th=
at being said, I had proposed that the problem of identifying domain relati=
onships and boundaries was broken up into several areas, one of which was &=
quot;cross-scope&quot; (i.e., public/private), which I believe is the part =
directly addressed by the Mozilla PSL.=C2=A0 Independent of whether the pub=
lic boundaries are drawn accurately by the Mozilla (and I&#39;m not suggest=
ing one way or the other), I am curious what the demand for identifing cros=
s-scope vs. other relationships is in application use.=C2=A0 I&#39;ve attac=
hed a problem breakdown treemap, where aggregate area represents demand/use=
 cases.=C2=A0 In my opinion, making the problem demand tree map more propor=
tional to the demand and use cases can really help us understand what we&#3=
9;re trying to solve.=C2=A0 We have lots of conjecture (including my own), =
but we need real data points.=C2=A0 Otherwise we will get caught up in eith=
er justifying proposed solutions or arguing philosophy.<br><div><br></div><=
div>Best regards,<br></div><div>Casey<br></div></div></div></div></div>

--089e01228114ecd82b050812f81b--
--089e01228114ecd82e050812f81d
Content-Type: application/pdf; name="problem.pdf"
Content-Disposition: attachment; filename="problem.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i2m7s1fo0

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWEtz3EQQvutXDOTBeonH854RDq84HOBEyluVA+FAuZxa
UmvAMRR/n69H6h6ttH5QSYH3ILml6cdMf19361q9UtfKJ22yy67eGGOcyrbXPf5UDEa9v1Sv1W/q
5OzGqosbZevv5qItiznWt7srlWPVlRTL1K7JyA7+PGRzkyTbqrdrsuJgpTOKfrByDXN0a1XuNZyE
mzFm7XPo1cWVerFRcJF+uFiozSU6dYx/NlfqZLNxnVWbt+ontfrkSBkd1OrT8froSB0b7dXqcb3B
kyf1JqrV0/GVz+jq1OrNqj6x3erNEYls08Kvrj8f1zxjbaL/eNSi+QnUdTANLSek+We1+UF9t6lH
sYzV9LfEGqP2sQ8UazfGik0aYjXVFDxn9ziStTghfnJwamXrKt/JFvFqvrZX3dpzNGE/hmlCdTEn
tZcU6UA+uAP5QLKtym5MzGCjDsYGZFjEhrgSo2IZ3hSZtQHvxUBWeO1EtlWv18jkefLt53vH+f7j
5fuLyz/+/OuXnXr/K/IwhKhNb/qabd4U3QdYSkVbXKOykKQYEmXlyfdXVr38vaPNcM5pZ4ury5C5
Qw5bZHOm9c57bejxsMxhGTKBFkoEHOn/Gr2p2M0l0znUWJDCBGcWLd2liM63Vt1sx4ju3ngmmj66
qP5GLr8bOOfsvAMKe2P7BHjo0AdrkVdGZ1//1PkZdmvfGSKEh/hHqyLOtOAAQQYu+lIMUjbG6BKI
sMmQZaPMF+cS2GdXbY6ruybdqnPEOxIZwqDfYSJzJelofBiJzCMo/HCxJmnkRFLHPi3AHRncCyZL
9Ql4RW4yvztKulUZCUzoSYDMKA93IBq8PkV0BfiS4W9HdMxBO59cQy/oweEUsksd53lF7yBTFWcp
WEI5r53IPgzRNnpdGJrEE8BxgB1wM8SwDWg2RHtGtPVFB58GFPigjU84s5izzmAHH9yUB0IDtATA
gVLBHINvG0LU9V8ET6nf0HsAMEt3B0C7jwJokB9gR4B2FdCZ7orz0ZsHAvqgfwT6ZCNQVSbgvVIW
bYF1fiLbicz6aHOkFmSyumvSewEdi6WEQAMFEuyLKyOgkUO0r7g4ba311qtjWxaAnncmfQUt+pAv
CKvoUNanjE3B8/hOt5KCLo8E0MwPd+ib1G4Uq0ntJhhMkV7/vRPpodZVpJTrqHZLTeZkJ1ZlBIvs
MKplLSO9anxA7eYScjKv3fVcAOrhPATpBj0UI51uuqEIxwGz1ypZtH90hD2qfGWKaM1Q973FMyKB
YUmawHzsUBqffUDkSEriuO6+ruXWyO+H+byhqptwvvUfBeZB6rbPKWRDdTs5gN8+FOWH3ANOHfLT
WeKPVrWLCyV7jQ5NhDslwgbotvxWlNOhz+aPaJMOtfOsaXMI5UQDJqFsz1FeR4jNu3mbLyp9CchE
UUk8ZExQmwsij5FD0PAYm6grWain8eY5WAOln6YZXGiWwYWgj0sBORwaM5r95Kp9OnuMVNV83DeP
FryPJhUoLDxcobPBwLFCK3uk7oou2IX2WXAeU07uKz/uK0do/vnjJz36FgTCfNXVeWkxksZoNdq0
gGpqqJgTgyUPkBs3ke2aDKDXIYUAgpG1LKvQayNpPYZ5SsSic7WHhg3jADX/HfZvcmjL7UJEX47D
opA3d2XM89KunTKJr2U65T1YJFPA9GvQgaCJ0dZnTOv1MJFVlEH1cuyW5ecr8aIZk2IinSR7OOkb
aYjF2Mw+7/vFZwO4Y0QInnppbtgBz4EXqC9msu+Y7GliPNABiWwy0PFaNZHRZ4TO4cOFwRABBwPK
bqbCH1GdI/p2cAeIKJbybxmIHSSQNAqBPgM6s74v8NylnPqemhkR7kRIdktPM3Bb3jXh/X0GMxDi
0KUE7jMqXF0HtmgjBFrbUGwAoiCbfx+IyCqg6VFK9xEDKLZaGomh6UeXW3r6/HBAvXxbkGSR7w99
/fSB3kaSbj9tDvCufPfpAWSelWYIW/RUgSHGeXtK/FjzdR9JkGEnJj0Thk0ktXguT0TCiPy6KqRt
rDfo0yQmgS8FN1j4ZoQ8o+W0PToVBU0mH6WG9/HlSTTJ7ooqvmHPeLel8RPHnh4N4YkOUnuoMsim
o2XzwBKTyb37HuTbk1hnt9hNORKhtGFzpkGuxUO5masRapIbNvCsJhlOsW2a7CefQ3vE7bckiLw7
+tfVMgoCQSEdp+e2+tt6wHgky1+MJ33GR99efsmOyd6I7zUf2km8+geRtE8nCmVuZHN0cmVhbQpl
bmRvYmoKNSAwIG9iagoxNjc3CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg
MyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgNzky
IDYxMl0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIg
L0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+
IC9Gb250IDw8IC9UVDIgMTAgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgMTEgMCBSIC9JbTUgMjEg
MCBSCi9JbTIgMTMgMCBSIC9JbTMgMTYgMCBSIC9JbTQgMTggMCBSIC9JbTYgMjMgMCBSID4+IC9T
aGFkaW5nIDw8IC9TaDMgMjUgMCBSCi9TaDEgMTUgMCBSIC9TaDIgMjAgMCBSID4+ID4+CmVuZG9i
agoyNSAwIG9iago8PCAvQ29sb3JTcGFjZSA3IDAgUiAvU2hhZGluZ1R5cGUgMiAvQ29vcmRzIFsg
NDEyNDM3IDAgNDEyNDM3IDEzNTE3NTMgXSAvRG9tYWluClsgMCAxIF0gL0V4dGVuZCBbIHRydWUg
dHJ1ZSBdIC9GdW5jdGlvbiAyNiAwIFIgPj4KZW5kb2JqCjE1IDAgb2JqCjw8IC9Db2xvclNwYWNl
IDcgMCBSIC9TaGFkaW5nVHlwZSAyIC9Db29yZHMgWyAyNzc2MzAyIDAgMjc3NjMwMiAzODIyNjQ5
IF0KL0RvbWFpbiBbIDAgMSBdIC9FeHRlbmQgWyB0cnVlIHRydWUgXSAvRnVuY3Rpb24gMjcgMCBS
ID4+CmVuZG9iagoyMCAwIG9iago8PCAvQ29sb3JTcGFjZSA3IDAgUiAvU2hhZGluZ1R5cGUgMiAv
Q29vcmRzIFsgOTI2MDYxLjUgMCA5MjYwNjEuNSAxMzUxNzUzCl0gL0RvbWFpbiBbIDAgMSBdIC9F
eHRlbmQgWyB0cnVlIHRydWUgXSAvRnVuY3Rpb24gMjggMCBSID4+CmVuZG9iagoxMSAwIG9iago8
PCAvTGVuZ3RoIDEyIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEz
NjAgL0hlaWdodCA5NDQgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNyAwIFIgL1NNYXNr
IDI5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh
bQp4Ae3QMQEAAADCoPVPbQo/iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGPgO
DMhmAAEKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoxNjgxOAplbmRvYmoKMjEgMCBvYmoKPDwg
L0xlbmd0aCAyMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMg
L0hlaWdodCAzNTAgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNyAwIFIgL1NNYXNrIDMx
IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4
Ae3QMQEAAADCoPVPbQ0PiEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwMDXwACS0wABCmVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoKMTA0NQplbmRvYmoK
MTMgMCBvYmoKPDwgL0xlbmd0aCAxNCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl
IC9XaWR0aCA2NzkgL0hlaWdodCAxNzUgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNyAw
IFIgL1NNYXNrIDMzIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Cj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg
wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB
AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM
GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABA2cDA3DGAAEKZW5kc3Ry
ZWFtCmVuZG9iagoxNCAwIG9iagoxNTc4CmVuZG9iagoxNiAwIG9iago8PCAvTGVuZ3RoIDE3IDAg
UiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ3MCAvSGVpZ2h0IDM1MCAv
SW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA3IDAgUiAvU01hc2sgMzUgMCBSIC9CaXRzUGVy
Q29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dABDQAAAMKg909t
DwcRKAwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY
MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA
gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED
BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDPwMDiCUAAQplbmRz
dHJlYW0KZW5kb2JqCjE3IDAgb2JqCjIxNzUKZW5kb2JqCjE4IDAgb2JqCjw8IC9MZW5ndGggMTkg
MCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDIzIC9IZWlnaHQgMTA0
IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDcgMCBSIC9TTWFzayAzNyAwIFIgL0JpdHNQ
ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1
T20ND4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDLwMDAOmAAEKZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iago1OTkKZW5kb2JqCjIz
IDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv
V2lkdGggMTg3IC9IZWlnaHQgMzAwIC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDcgMCBS
IC9TTWFzayAzOSAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+
PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20JT4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG
DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw
YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA
AQMGDBgwYMCAAQMGDBgwYMCAgf/AAJGKAAEKZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iago3NTgK
ZW5kb2JqCjM3IDAgb2JqCjw8IC9MZW5ndGggMzggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggNDIzIC9IZWlnaHQgMTA0IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9J
bnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4Kc3RyZWFtCngB7ZyHetxGsoXXEkVOzjnnnJhlyet9/7e6/6kGZoCZIUWLI+76GvhsiQS60RW6
qqtOFfSvf0VXJIFIApEEIglEEogkEEkgkkAkgUgCkQQiCUQSiCQQSSCSQCSBSAKRBCIJRBKIJBBJ
IJJAJIFIApEEIglEEogkEEkgkkAkgUgCkQQiCUQSiCQQSSCSQCSBSAKRBCIJRBKIJPC3kMBvdr2J
1LePfNPr/uKgD1z9A5d6gxCMmuAfr805jHtt1K969oGrf+BSb5EW5Hz69Omzd/HjJxH40kwN1lAb
9dKgX3b/A1f/wKXeIi7I+fz56suXL9dc/HV15XRwfq5GX2m0Rr2szPOT3333A1f/wKXeIhaR8+X6
JhaPJ7ji8Vjs5hodyFjOTPdHaxSDzo45M+3oludOju7++NfLrP7jdRhxmaV+ltETEiHn6jqWSKUz
2Wwul81mMulkIn4jRZ3RgRF/E0+mUqlEzPR08sIf34B2eVbef24jvDL/Iqu/8v7Ao4ss9dOMBghx
P0IOWkpm8sVypVqtVirlUjGfTSdR1Dk9/fbb56ubRDqbz+cyyfj11TlVnqxxdEMSwG++5lmPZvi/
XmJ1/10/+PsSS/08oyfEyePFUrlSrdHu6Gq3mo1apZTPJDGWUyVIqfFUDp2WC9kkqvyrBoE3IQK5
0jn4gsGekHi4cYHVDy97/acLLPUORk9og5ybZLbc6A5G48lkPBoNB/1uu1ktZlOx6xN7ku3dJLLF
ar1RK+fTcY04eeXrN/SKLzecg/HYeYN9Zfr7V3/l5aFH/2VGQ7TwC7b9JZ4p1nvj2XK1XC7m89ls
OhkNOo1yLhWT3wvNkO3dJHPlerPVqBYziXMGF5pgSwQtTvxzFHISZjjdvpwYrM7c4zfsf//tk1Yv
7Vc/2Ub7ke/94b/M6DH5qOk6kat0RovNbrfdoCldi9mo1yznnFOT4PwLfyUXWa63Ws0aarq5Og0E
3Fgt5M/y/na39IZktlDiCMxogYNjDQ8/ptRmm5r2q9smCc/Sb+dm+vdORweGBx4eGG3DaBZGA4S6
l7nR9nNgon7UPbbjOxh1Kxz+lBtJFer92eb27m63Xi4Wi+VqvV4vJv1mOStrUTxmcZn+4Ogn3uAk
azYb1YLU5LLcvWzCBNsMy5r5yejnVXKyxWqDF8C+GazNdsu4FNsffaDT/SRqk1lbvVLIKIIJUudy
brfO8Uz73RHHy3WFyOKxPXSP7OkRo+wnvdlXqnvV/k//fQqLLsHoMfkwHksXm8PF7u7+drOcTSaT
2WK93W6Wk169kEaKnx1DV1zktEqwkHKlVq9yNiWI24nYDjkWdDsBGL+K5yxptpTZE+nVdSJTrLV7
/V4be5Q9EYboYqJb4jD6DLXMLmj1Uj6FmiQVp9mjqccz9btbw4Z7zIh6J1Z7Zq86YVSHcIIkMRia
7l9lfDLvwowek4+3j6VLrdFyd3+3XU6GvV5/ODEHuBi1Kxg7nJikb25uYu6KE72XCNwJMuIxB1yY
R/jN5OCJGqaYiE4tayZn9lLmz3KahWpnOJ1Nhu1agYDSUmlJ+8py7DiXRqP8/d71qcaRKM7U6sSZ
munL5xry/JlGjT/l8LfckMeMRvvDPUW5h7BzzGi1XMylE1AEQHPCp21Sxa0XZvRAtfsJNcUz5fZ4
tbvbraaDdqPeaPcny+3t7XrWx5ziNya7RCKZTKXT6VQqmUimMgTk5VIhmyJa84VqHkH+WBQLooDh
GGmwsmZS5lQSlSJ6gjyOwtZwtt6s5sM2fk+Bv3b4l2sNzzBcCTajz0hb74+lONjKZAxKr01Ahp5o
Ja40NLG1TjVsh4XbCGAtYsaGkx86m0SF1zcCYs4wmiPhN3wGDsJ8sp3kYS7O6Mtqut0s2N7lUrnW
Guik2i1GrVI2CeWpNPhEPl8oFouFfDaTJrl1akonHU9JjM7oR4pCKNIoE/Ul0GehWCLFUspMYCem
buLpYoOj8O7+boOeOJ7Jkr9I3Da8VOYqFXKZ1Ln82tSk+ENqQr/MiidtI+QgT3OZmj6b8cmWRJyN
hh03WmRpIW0TPTzLaDGXZYfaFjjhE8O/AcK5NKMvqmm7w3wapVw2V6x1ZFy3q0mnksN+HEBRq9Ub
jboS3xw8lsErSqgsk0URCBUHZMcEtpJGYkAUaZSb5wxrNFtcTR1lwBY3yIK4cry6e/76/LCZD6Qn
BCVx40pJxzSc0aaGE6tA1L7Ts2lIKJ3TRqhU9lMreqIYMMwqahJ8kkPFDK/WCOpZqMFC7oQ1yoXE
nDCK18trF5zjE7gG+5N3uSyjYdo5Vj2nt9xuV5Nulc2VzpUtorhdT7u1QjaTLVTqrU63y6nV63aa
tXKxWEL6DYkS6svwVXGhAH7jhgOeO9UympKSmu1ufzAYDga9jmXM4qlY7893T9//+P71fj0dtAgY
zWRzRH82ejAgunD5tWw0SLHURABScck1FptI58nh2gJQWGg4HA567fpLGd913Ea32ozv9jScTJ6F
ZJcYsx6eYdRAGXZCjT16xKe2agbzLJQvzWiQaf0cUNNyjPWkJMfGYL69u91Me/ViDuk1e8PxZDqd
TpT2NmuVclXstNmJKIwfuVdUdIx3j6cLCLvdqldKpZLEPmCqzR0N2vUSxpnOsguWd1///eef3x53
i3HX7mKy5Xq7NxwRaXKNh32Nlo0GwwizCKwRXKvF41QC0Vaawk/G/DeZzubz2ZSMr+JlfAFmvamG
tox02fDZdCx7Rk8xIpPKeUZZq1ZlL5zhs1mTcymg3ssyGiDc/XheTX2paY2aSoVCpdmfLEilVkAU
RIKtehUt9QbDfqdRLaOl3nDYb1XzQEtfyFvFK7bTrldxQ454pEc2Np8OO4g2k8mVW6PV/e9//ufP
70+3y3G3UcZ5siEb3eF4OvOu6USjlVUGgwEdL6QP9XZ/0JMVplLZUqM3ni8NPpnPSflWq/k+4wtp
+JNC2mK9O54tHNYyn2v0YjbsSE8J0rFG7yyjA7CzRqvTP+aza7aIhErVZrevnfxORk+Uc7gRUFPI
6W0J/CbdWqlQ4qRabu/IfTfL+WTQ5dyoNbtDdnwfjdUQ7mQ67jclUhxHBl5HGEO3WeNZS46IfTtD
IuvlTAFDLpv3renf3x6381GnXtaGrDS6o+lc1jA1btFqt150oCFJiruI2hWXNvtYT5dzNJ3JV9oO
PyExl5rWmw2ZebdecECXPxFb0qmWLe9Hg4m54SvIQuNp7LI9OsfoFKbbaGk0PeUTU+QMwOV13s1o
2G8cFBS2ppUXQuRdCEFEvl2OiJfZ5b3Z5v7x8eEW/tFSrVqptfrjmayjUas1e6P5Yj7u1sg2cRz5
ans4nU9HjOMwxlHoSBuMpovVZrOaAmzw/lK9N9s9ffvj+/PdaoKH0gGNLY20zWcCf8dT7INt3q6a
83IZpP5UapXMkXSBOw5axCTZQq073dw9WGY+ZTsvyczXBJBkfIIoApfOzVzVH62FxpO5hq9mA5GV
LdbOMjpfzMb9Dt57coZPmbysCWN7N6MnQU9QVZ41TVa72y0JrR+Qr3cEfpBfKJSbg8Xu8fnpgeSX
tKpa5sxpDSaLJbqRmrrj+WrJ0BKBgI41PCSIYKfB4WTRV7PZ6vRGM0KUzWLUqRay2UKVNO3++Xci
vRnukuNPweUQEeOwhv1ez9S6Xk4JPDnyyK+5SC31B1lTvtYdawlsgC2lcORBe2g2GvT7w+lig+Cn
vZrMyZJfN1OTY8m8P3o1GxEPYSDLDU6CTVbM50uNweL2DKMrdmen3YHlIz5RoPwDmQondKPxLkaL
4D3haCmoJD+E6EzWYEXEXXhhDBgYAqGOcdrscw7826fnR3Z+v4UTlINqDqZLqO81OKY6o/lqzdhq
Pp1M5yptxI3W2tVSAfItUqaS1R8L2NBhV8xmcghkvkW2u/mQE4bjCmPqIzES3hEb13buGuc1Ukij
RNkDQMAHyLoAICeszorQItmipnu8Z7fVbCLMJaTPtWtwwpZi+8k2kXxBmvBGN+v1JnvDvMgAky5W
XmCU/TLotNq98QKkM8znlIk6WEnClBL8PKNm/UdRbUhPZk2VzhS/9nC7mrKZAYvmuCg2s3NRov7x
6Z6d36wUlOflSqiJswY1VSwXXq3xZxwVmSxHNJtOCrS4gJgcz01Y3h3NN7e3iK9RyqYzhWp3sr5l
W3D4keQQ5emE2cqAR4TiEslc3khatWDdQANy5qROegyW1QkR2USemqAc066Wy7X2AMFjtm0UTFNH
3J8pDMFCWNTkRqOYMnuM7bMlxMWLVFsvMard24KFM3yy7VLAH5ZWvYfRWj6paCmkmuAvvpq2D8/P
j7vVnKibA3+tLdSqkBRkSyRRsLZb4vAxGI9bT03lUoXwiOHCfTAf7IyyFXEBCZdib5FPktVkK27v
7neLIaEGeibWQyvbxbBVBnBKpgu13lTmvJE1tTiuzfhkFGWF8GxXJZekYuTTmDeqYJMc1ASewR4q
F3J5i3fYYjwkGwN68mdS3EoSFiohFPqhHUjMySk5Xdl+YMNVATbPMzolWGq0sPdTPuVDDD17F6OC
5VJvUtPu8XcOC6+SsVRMp/gn5Xbg7u4Oh1VzCB9ux/YzsuD8LFXbo/laeHoDnMlcID6vJfEaDFEi
ycIXTVdI4G41kl4krsF8sxXqUUwnSFFJ1OS62AvTYY9EeogHlPENW5UCoSGYR61eJ7sEDiBnFiAY
VNP2dreSM/Iyc6gxO0SlQA7eTMFPWcvb/dHpRIJMScEdhJBkV2ptlQnOMYpfqRHS4vWO+WTXaeMK
qHkXo4NGMRV7gzUp9Pr2+9Pddm0pyHTE2S50IIFOOEhud0tJWHj5NQB3XW7H9jMoBADdaqOwlvC8
pRQLn+d8QRYgHVAGaGE8V7B4vx63UZMFGoJeQTkUH6Km5mh19/T8xD6fgFgMxzoydlIToaYXSHW7
HQrGghzbw3lQTXOigDlm6qgVaYop8bq4XMvDNbOueJJwaMhorFhHV0wLw5zOMkKBqtT0AqO9Jlkg
SOcpnwVtM7T0LkZtv77Jmnw1bcj3pmNcD+cQnNzYsTuTIEzhBE9UuQmYPDVxiBcVeKmM2GvJgRNA
4PMsESFltZC8P0DsO5zqw2ZiaiIKwNmYngEaYiRbrfHm4ausmYKXBeQrhLckT+UEwa+2yaaHQ9IX
S6jDaupzjBmYDzJIQlDrTSRMzvZCoXiYiZ4KZOot1OSNBh8iaqQeurazjD3Ge19g1DxFoyvvHuJT
JyBGCT72TkbZr288m+T07rfL2XiojpUauaNCJTMdOJHPyydVcSBz8dSkWIu4rQzvmAanv7wVUSvx
T1loAxhdR/IlD1qsCXVNTRWsaa+mDolRjJy43J5sWP/rA4cj+Qz58AKjJjGrkRGQ44MAjMYjcA+y
sUq9E7Im5LxRYs6bVFcmOlk6NRUDM3vtRqWI2loDSHW83ADWJ9Hq1NTUqVfrUv9ZRs27F8kIj/hU
Us+RR5nynYwSBuQSr3b/BEIIUiMlsOjI+r/IWIwTTMcThN5Ev0lATQIeaXfBzwAyjEDk5sAvBtOR
0lTBkdSsBIoyf4OasCa2yXSM3Qi5EH5YV1gA0IrbxJjYPrKmI6eHy12bmgwFyYK+k3/JmqQW4Co3
s8WrLMJxJ5c277GaeK+v8SNGFa0or5I/DfFJnEKcWngvo33Ko+n4qzCEqalsAfn9bjnutdARx62K
MDKdgIerZnnTsZrIlfLVDoEZhxr4C9ifFfuUXVUNq5ALxZyW2/unJzm9kDV1a87pyZoenr8+KkkV
DC84ngOF6rbiAKQt3LPTVn2DcELiPIQQUpNAYx2ctKbt1YRapGFvJuA29ReCRN9ggCCvzZrk9Dib
dLB6EeQpo6oUkJWH+ZwR4CgOBfwVKPMORtUT87rP8xBy0lvyGKCbBqkR9TuvpBnycJUzahKgbnEb
qMV2vVoBqTlISPCPYaKKCUCLZmullSE1HUIInU1r1HgPDkLe1CCq439JVnXHNFVAVYFAqSgunkR6
L6mJyhm1sP1M2MI/W4Rp5yxlaStQmt6IVWpAYKYmafx0Pxa82SE+SQIVttI8B7j1DkZdw8Br2a1f
yBBYpMhK3RnoSEX/TwZXHjzcGeopGCgWlIMnlL3l8qAXGROuXLYlQEyJ0Pb+4W7tWxMzdNCrKYZI
KUM+o5QFGIT6heAoXQXVe5WioijyL5c2AbYe5U0vqEl5NA7Jn0mV0vImRa2AlSQMCqSznKtyBGRd
XijnDPNUTfl0yrx7kE+SQ+UAikvex+gb2ryd0wNk29IK4VIjeTtrt1ER7kdqitFnVGmP6Xh5fHx8
oO2FnBUARQEgZzmqGHZb4E9Dq6qjJgXkguXk5oXpZMkOvQIXThckViiTLlJZ2i0NKRKWoAsQwlAI
h4F46e15NZGRCb/Yz9SHJtQTG35qRMZAr4ARSXOi4SkWcb+spqSyrDCflB/x+ZdgVHX+VzAIH9Nj
/Y0wk4p8pKcjPfuRmug3kesQOsvZ8vXZMCU2smAjxVCCnztN5bdOTcqbkglw9O4ETGdpkTt73gbf
ss09NQHG4rL0uQFNKWCn6vbxrkBy7cCiF9Tkum0EB9oleE9NGB6iAsZcwn9KMy7QqwEUO3TjrNPz
yqVhPoVkeVHr+xl9k5oAb9YgYa1yRvZOlcbwJKcmMhGQTnWD7X3B4RbhFcAzJYDtw9dv3789368n
ljR5HgJ/MuxYPjWnR+XW0lvUZPtSIA2JkaDLIqfzEvRIrU3UfUlp5eLU4yLL5kJZdgkh30OvpiZ2
g0edF0KADpIT9OuqU1oXmk1U5xdTG9SNn54fthYzkPsC4srnWVxo8O9LjMpHKikL8WnlY+WAaw7m
dzH6JmuiTw/3SojWLKWDkIWpKVcDkFvCl1OhAvLDLVcLpNpGCPD1+x/fnu8MrVBqJL8GDrPwijUU
3IhR6FXCF+lMEOYJCE/tFoUYFuiNbjeIFbgAhtSjINveXy70ZJNAkCuKYIf6RdSZmkjBhvMlOaiF
3KG5RK2oySoo9wi1azUkOkdFhQXch1f5+zHIKGn4EZ9CMqQ7eYZ3M/pja1LX62C2WICwFEOQhdRE
KY1SxRzUq5Sx7iGaVgO3lFzFUsLkbp+/ff/9aTdXc58Hl6kcspxSBzIYgvqvQ2kciIe3wSVSWgTG
UYkYAFpJyXiA/Gj5seYiireu/dirwlIY3K8uJJgomdqyRx2kXMcJGgd0RJB55/z+djeXkqKnpq+A
YkT+lifgQwg4/bIgpbMXGU0QGB7zSdZiJzNb7hKMvoyP6/y5kh/hg4zZyCCLwFGGmr7Es6TulNF7
oKQxbe2jW1TrVBXtTDb3z1+f7lZjnKMDgJpClCghTUlwp3OBdIbppF2Rt6vTkOwHLwfSUFT1Vr0J
VFX15Q7JE6ms+5Qg0NEggkiN2iIIkFuVKsoPHnWo1I6f3phGipYr3x44Z+peTfjmLSup9K8alyuy
q5ryCqNxjrljPpVQx9OW9l6E0WDl4uhnda8BsbQHI9DWI8iCiPyLyOgCAbRpStHnF1JT4BYGhtN3
EKYOH69T9ga4TGkoxwQYIZ1FaoZQgcPQIeChEkpUuYS9Qaomt6deCEFEKqUIGOq2SPqsZeVAcZAg
apaqiRyoo1qLYbMs+BSNEkrrA8GTPIOc3vIea3q+pxTARcuKKFAskFD3y6uM0tsa5pP6sCEZv4DR
A8veT/bhTKYEHtNVJxS8HXavNU2lyLLp9lKbj32VBjIRuEVcKKjC2o35Pkr+Q3CA3I8K5xMahabI
fUKbAl9NIT0dISCFORXq6VCZIFFl1MC0jc6AziJ9XoX9oaYm+K19P3WgOUgQ31+R/IKn+dQR0wqG
ECsAx0QQQVa8qNVCiK/Pj7d8IUS3E/1OroOJXmh6yQAPX2GUtuojPr2Wt1/A6IHlg5rYgzmaNhvA
rQZZ7D0FUvG6F+vgNl6vzskt7EubuAU8OqQBReMIq7CYYo0+MTriKE30dYF/kmkQFaBE2vlA/HgG
OgXKS2DLxzjWLwbyym2MSV2RR18jhgmyGqU+XHTUmdCgpExt6vQLObOmfF1F9ifyaGxcu2c85LMQ
cjfB5dam+SKjevsJn59dA+nlGT1Rkw4npEaHb6l4RiyqW6jmpY8SrGcOdkO3cCz2AjWf0lSMNtVX
6QapXdbAOHUB09hcRSF6iv2hJ3soLF7ARwyn43pHBeeptGT3MdaDcUO7vm30CFIcqGM9Q33YUeeE
JlaKlMqOEkZfTTQg4vHmmCu9MVaIYqxtHftM/DVGrVs0yKcCSaPn8oye6AnOkRqwClm/AqugWORk
aMjRtwvKYSyjOnNLetJnEgA8rn3bka+GbfVk025Oqz/JkBBd6VB7kCZTPSTu1lcpJJ+mKFXXdBn+
y8YIHS+mpgBB6t8kaztQZ0Kj/JPhiw5MOsyKziaVlza3aGlEcUywofsoxqHMoVcpPAwsJUK4jvnU
IPT0Cxg9UZO8tr78oKnDspS9y9NIozX8OfPJLZFKTTdBzwJfrfAOpcdGvj5/4EsOuiWztCsC9uip
dG0TBNXxRFiDNXfpFer94NMBdT3YfQ0OURxaXXZJrCXKvT0koRkrwBfhqazpgC+XKNFYTYOdLaPv
ebSvjr/bDi1lO/Qcn7+K0RDXniogkf187h8AEPzKng0+O7llYkfTMft6zGnJ3ZPIwLiB4oBQcVHe
CsGH2hz64kxi0mbZo3fAeabSI3qDq3uz9tTZ7vBY4VlIwU5Nqu3SBqXaLs5Dn/egYFsm+F5PwUe3
/LcH+IS2IC8XZfSIb1vJvkoMfJt5GCMyQFqCz05uOQbU7MhAn0dHv4FqkqO1Q/pv8Tj2/o2kvZik
KWvJQ6EeSB8StVEVWl2S3FPnvlb0b7DGgQuYVOiTU0PA0lAHwBDbN56SGP1jRh3ZYT7RExO1N8AO
L8pokHqPc9jVxZIvPgw8E2Xh4e6OfMdhmA2SEN2Hj/4Mt4L38DP6N3/CNN1yw92U4LuCVNlAt5I3
K7Bs4GFwjqmJzFh9zXO1tqkkr00lo3NM610+jf7Uk1vuRphPGZRPufBH/yXvZtSn4vC3aNR1uHP4
yT0JPXvlVvAVGmZEmyzcpP17/Yd22+76d9wU/bYfHPrBZvhPQ79o2MkNN5ctr68EqCgrfXPf+bCQ
RvsvPzPz9JZ/Zz/LX/MXMOoT9uv/PsuVv6z30P+Vv/fD+SFw+wI/smH0yb73zY0QFWfFF3i1vWJP
+bkXfiSj59b/+9yTmkAR+GBM/xwH8AZa+vtQ/8+hVDEEH3WWyOKKnEzHGdk/RxD/25yaOelfmONj
fJfH/2/T+w+lDjWR+9q/hmBZ9qUPv3+oWC/OtunJ/m2R84nzxReMXvhTEpCe1ABjnVORMf2UDD9i
EnoigQ6ktB+xaLTGX5aA5S+hlPYvvyKa8BEScInmR6wUrRFJIJJAJIFIApEEIglEEogkEEkgkkAk
gUgCkQQiCUQSiCQQSSCSQCSBSAKRBCIJRBL4fyuB/wM9WA2TCmVuZHN0cmVhbQplbmRvYmoKMzgg
MCBvYmoKNzA5NAplbmRvYmoKMzMgMCBvYmoKPDwgL0xlbmd0aCAzNCAwIFIgL1R5cGUgL1hPYmpl
Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NzkgL0hlaWdodCAxNzUgL0NvbG9yU3BhY2UKL0Rl
dmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHtnQlbIznSre9M18K+7zsYDMYGDNjYYPa9oKp6me///5b7
npDSThsbZ3p6pqt6lM/TXbaRlKmToVAodCL0//5fuAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQ
CAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAg
IBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGA
QEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAICAYGAQEAgIBAQCAgEBAIC
AYGAQEAgIBAQCAgEBAICAYGAQEAgIFBH4B/1T6k+9Fgt1T1C4YAACPyjcaXBo1EryGoa3ELZXhBA
2v75z3/+8ssv//wnHxO30GO1xO2HggGBGAII6S+/fPjI9eHDL8kFtcdqsRuHjwGBxAhI3D58+tzX
39/3+dPHD2jURFV7rJao7VAoINCCgMTt4+f+weGRkZGhgb5PH9CnLUXafe2xWrumOv8Ws30TPVTn
lsJffnIEJKV9gyPjk9PTUxOjQ/0J5bTHasnBciKKzewv9z15/VDy74QAWvHD54HRydnF5eWl+emx
ob6P2Kdde9hjta7t+gKSSVvU/fLBX7bAk+Hc/dmS3iSU+ykQ0CvX3P2pf2RyfmVja2tzbXF6dOCz
Tfud5aHHaskh4QYS0Q8fPn769Jmrr4//ffrECi+tLyL5PUPJHxMBZMGuf6JMB8dmVzZ39/by2bX5
yWFTp/6vb57d/44cpar2pp3OP3AHhBQRZVE3MDg4NDTMNTQ0OOBWeGl8EZ1vEv7yUyDgZAHlxFz6
sW94cmFjt3hcOixsLU+PYp26P7z1ovZYLQ0kTkg/fe4fGBoeHRufmJzSNTk5MTY6MjTY34cvwty7
adoMZX9OBLzCMk/pR+b86eWt/VL19KSYW5sdG/yM/1RuVElrkynYY7UUGNkdPn7qGxgaGZuYmplb
WFxa1rW0uDA/Oz05Pjo82M/jtTxXihuEoj8PAghD5CnF7OsbHJ1Z3SlWz89Pj/Mb8xND/WYP2hzb
JA89VkuBi7tD38Dw6MT03OLy2sbmVnZ7Z2dnezu7ubG+sjQ/MzU+wvOZdzespVIg+zMWlTPJeUqH
sfkGh8dn13JHpxeXtXIhszA5wk9DeFGHhwY+a9VfF4ceqyVHCCn98PHzwNDY5OzCyvrm9m5h/+Dw
SNdhcX8vv5PNrOGMmBgZlF2SwB2R/M6h5I+HwD/+gZQODI9NTuEpxeQbm5xf3z06u7w6L+9tLk6P
jTDh8rfJ8ZHBuHeqx2rJ+286Ht2Oc2x1cyd/cFQ6qZ6e1WrntdrZWbVSPiru5bIbK/PT48Mo1CCn
yZH9KUuisz4NjEzMLCwtLy1g8U3OLG7sHktMT/a3lmenJqdm5heXlhbnpkaxU3+J1GmP1RJDJCn9
3D88PrOwupnbOyxXaxdX1ze3t7d3/HdzfXVRO60cF/PbG8tzkyO4zeoPlvgOoeBPhIC0Yt/wxOzy
+iYW3+rS/PzCymbei2l2bXGO7+ubW1uZ1fmpkYFPkdbqsVpiYMykGBiZnFvO7OwdV84ur2/vHx4e
/fXwcH93e3N1flou5rdW55FT7ZYlbjwU/OkQQB4+DYzOLGV2Chh825trq6vr23ulGtq0UsxlVldW
N7JYhXu7W6tzE0N9kTT0WC0pPCalg6NTC6vZwmGldnV7//hkVySo/Ptwf3t9UT3e25Z7tz9M+0mx
/SnLaXd0aGJ+bWf/uFw+LhZ2slvZ3eLJ+dXVRfWosLO1tb27f1Qql4q7mcWpEaTBKa0eqyWEyEvp
9OL6zkH57PL24en5+fkJwbzTlM/Ef3cvzYqgXp2V97dXZ8cHtVuWsPVQ7OdDAHnrG5JD/7ByVjvD
3NsrFA5KpxfXN1e1sn05OjllzVLayy7P4Oz3NmCP1ZLhg0XBrtbo9OJGrlg5v0FIvyCkKM/LCy2g
WEZhp2IEIKh3V2elwubilHbLIrM52U1CqZ8JAS9vmfxR9fzy8vysUjo+LlfPr2/vbi7PTo6Pjk9Y
vFxenJX2syszoxinThh6rJYIGXmiMESQ0t3D6uXd4/OXL8+Pd9eXtepJCW/U4eHRcblyWru8ub2/
v7+5qBZ3VmMDKNEtQqGfDAFEQpP+eq54cnZxhbo6Oz2tXVzfPaC9Lmun+nJ5dXmOAbC55CZ9m1t7
rJYIHNm9/SNTaPij06v7py8vX56QxtPy0X5hV7797Z1cfq94fHJ6fnVze3N5erS7PjdeH0CJbhEK
/WQImOYam1nezB8ip0jk5SUT6sOTabAb+3p5Uase77NSYQn10VuAPVZLAo45EWzkHCKlzy8vXx7v
Ls9KmM14IlaWl9gwXV3LZHOFYglFf8EI2l2fD8ZpEmh/3jLeszS3spUveufkHRrs9evX15enB7l9
Ls9PT472ttcXp5jzo4VKj9WS4CRFDUtrdbtYRUpfX7883p5XDvO48hfnZqbhnbDZMDu/tJrZzh8c
n1QqpYOdtbnxwfqjvb2HEbne/tz0i5XR/5p+ff9LVOf9UvbXFEW7t5a2MV++e8OuRNR8Gihibae8
m9WMbhlrpuWj6UUclCuZnf0jFCrz/fPL1++//vrrNyTknpVUtXSQ31pbmB6Lb0P1WK3l5m2+apUP
/WVpa//k0knpzXl5f2djmY3RMfZsuYZHRscnZ+aX17O7+8UiD7cyM9aY9JthigBw/7a5Xz3e2+IC
miu3LW4/+nKq061KiqKd7xf9JWVjvjjWfvQpaqj9v7HmoxrtC7pfXfFGiegmUd0kgp7wlub8YRtq
dml9u3B4Uru6e3r59uvvf/zx+2/fXp/vb86Z8HOZlfkpqPzy7vtb91it0aVOn6RMmfI38qXzO3Tp
y9NtDS8DowSaiVimjgkzODQ6Po2gbm3v4OuFeiBXGY9mnW7IDl/5Aj+Ry/3acluV5w++SFTOYG4p
GfvqK1npqIp+ixWJPqYoGlXp/G/KxnzxRt8cAu0eU/d8U9wg6wyFygs7/ROrX0fF/alzb9rV6fCW
rKgLf5qYWVzPFo6qF7dPr99//+Nf//rX779+fb7H4XOAlM4hpc2BUZJToqbSVnv/sQHLbTes7Bye
3jy9fn19voVbsLXCjiikPeildn2E3ddPxNb03NLK2uqyFL3bxxVuDicHkijVsBA/cYmKKEzjD2A4
W2SAilhUgMq9HxcQVXLN+qZd202Nc6MUReOP1f5zysai4r77DoH2j6n7NRdPAEUcaipH9euoOBj5
uX1v4ves13kPfATjw6f+oVHN+3LsI6a//v6v//u///vjt29f7llIF0yXDb9lSPVSrfNDu7+gTPHj
Lm7unVw+vHx95QFOcIXNGr/ExAf5kyhCnpKgTs3Mzs3UhxDQienvXgkjU8UQ6AFdKOIWaqpD1kUG
KDTALisotrUmjjYQq5JvNqoz4IPFW2ukKNoNFSdGCe/bkAAf9WB9U8cspv3NYKV8eihiUEevJQqy
0O3qMLZHMXpElMinT30WmCH0G7Va9Ik9ImLa58QUt1RiMcUH30M1PeA7l1emq7mjGlP+15fH62pR
u0xS5SYGAKpLatLoh3D6x0Q6dX8V9a/PCaVGJrEpiuUeGxsfH3Mc6obVwqshNkYliAxQkQldVhDj
Qoo7Vrb+xP7toMsxkF2d8fHRkeFBgsVbaqQoWm++44eUjalvv/i+8Zjj49Yxe0w/WJtGoIqng4Ia
gloawGFlMto/OCRU/N0EYwsmjf7pHeoV9kEdjZCc0Fsy8J3Wb5TmE8Vh8r0ze+/vZJbhR7WZ9Huo
1nTrt1+cZbqwuVe5esTb8HxXO8qtz08MO7O4jq1Jqu/loIJNTKbA+lPfINEoY0iulId4/yjcufn5
eXRuREW0VvyLrEcGzC8sLHItUFCkReUoMHpt/Zb2rMJW4QTDo9LjVmeBSIIZgsWHB/1T+E6lKPoW
htZfUjYWFaf3k9N0f4Frfs4/5hvZobTrlQ+SSAAFVSKoifaRoBKsJrAnp2ftdtxtenJMhlr7lCR6
Qq9nxuW4Efp6RsDXu2uGUmhEUjqLaSrfaWwJ9Z0l1PV55Whvx5ZQ8YV+r9Va8W/5Lj9X/8jMyg7K
9MtXlOnVCaRXthXe5gvwwxGTErvT69JfUO9jk9gBs3gFcAqI94/ran0jk1lfXfJURPP8GkySt7FJ
RQZQZBMaGOG0mfW1lcX5mcmx4XZYSYdYpRmaXdvIUGczs0HbC7OqEeO96kUmLNqCQZuv6RqL9Q0O
5sraemaTyz+mBqufmfyNYsUTQ4HQeKiRfVrE7kE9ADa3AxXdDRjnWPb6wdvSKd2T4S6rbXaB9YXq
bFFrfW2ZWiSIAEp8nzEdoXHRLybfxs6ePPxvHVKV4wP4UQvTo5LTqGqP1Voet/Wruj84Pr9ROEGZ
fvv6fFs73LE92uZndtVMUBW6r/Wh9CtruqGx6YXlNZZVSNq4ea02suxZESe7g0PAe35dpDc2gyID
FhUZQJH9A137e+x0bW2sLs7K4DWxa2ClqdGseJjamewOxDEqUUORBNQQ7zUCKEXRVgzefk/XmBM7
LTbo28YWj7m3z8Vj5lzAw3jTMsMkJiUUDahXJY1TsOmh0xNkYbczVATjOk7E6GZNveKeNoa1Bman
xj3iAc+Y393eWl9ZmJlA1pghI2GT8ayXO6GY5wPt6sA9vmMPign368uz3PvXuPfLh4VtXnKM1tlj
taaHbfOFxyeydSlbPLt9/vrtVco0s+D4gw1padSToOqSjApumABTi+tbOzlBtDA3t7C8kWUPoFyp
VMqHjvHnA7oZzHJTzC6uERmwf3hcPqlU2RmuEhZQOjpgw2ttcZb4FVfa31DgMqLHZ6iUKyicgHYr
lRNfY0W8V5fWQHZv0qKN3nT6lLIxKSpnjRH1oMek+1U6dgIBbm83uw6P3Ajubj9RsKWGwkENgW2L
yLTM6gLk+WkNXTZcDkGFu1VPykcHddJ6C8vSOsRqaGoOj2JuT48YQXl8uJ9Xi4rJiMup8ITmsZTZ
RZWeX16xParNUkf30GYpv2izdC9rfNOmzdL01Tq9ieh3zfmEDO6WLh5evuFnOD+SMq3zsqJijX+d
gGrUqe9GSdzeKyoAZWudWRkhZezRByjUdfIMUk2nTfESGbBPZMDZOdvEV9fX1+r+ORSXo/3c5uoC
CjUmp1aLeQemdm7/yCpdsLUs1haEnWIhCz/b8V41ZGyK6la0oS0aPXrzKV1jlEZKoerOrxD14B5T
/adjBDycaGLUrGLER49aaij0RBHUhyaMi4vsCu6wfV2RDAGkwiuqIq27m0WTjHXOd0jDfWv34Oik
egblTUgKytNK6XCPzRyURDTmVcnuOD63JmKnkUyINKpd3NxDkru9gofCF0c9yb+lnqSv9uYdNP+g
Ucqcn9mrXD99Zc6/qe5vokwTcUnp/Me+kamlrb3j6ikIFXLbO7v7x5VzONWw/W+NouL2/t3cPT6z
hJ1zVIFxc0P0yl10aQKpVY7Z+FqaGY9lJ9LDSUpXt9gFodL19Q2XvRIkoHJU2FohXtyM6ORFm/vf
9lu6xiiNlI6h6bb3tKkIO8d37LbesXWbGJ3jRONpKCUUMagrVZDKbWU2UNzGsdD97gEcbjB0odL+
jm2y+0nG+uelFDOT4U5gBvIFiDeGJtFDNnnHYjLcLIqYugQSEZGv7Ih8d0bkKx2XICJ5Il8r39Ty
TqSr1vY9NH60MTO5yJzPAoo5/7KcJ1VAYx+0UfLtJ70faWJFxV5JzooHRd7TJSMO3v/j/XWtRKSs
ZB73o17N7PKmZhD4gOAK4douQ1h069rJ4e7mckxO/2HW0fjcanbP6LgWkoX6dVr4gvK5jcg+0Tw6
lKzo2460/JLmvn5O8VRdCOU36lrUOZHKry/PynAgjEUkOcVG7AGKOtRViQa05LwoaxVMRg0KRQOJ
x85OuyJANlgCN8ggphjrw71Su4wGu3BUrBuDCfE2C82tnA2PhpiKFl0tHe4X9oqlU2rrTfEFesdp
jX39t7RoJ6apqrW8gtavphCnV3aObc5/ua8dbS/DeI74Lq3Fm75L6QyMza0XyufwUCHLVisVqH7G
nnY8fy+mbI9IiGZXtgrHpxdY4hZZZfM9UN1CYUSqH6R9C8hpbH/rw6fBsZmV7F6ZoBdkWqQcph5m
rPOLC6Y4ozq6ZEaoqGRFE8z6vKDkjZmm8jZclTnxQREPvHgbTKZXAYZdPTQOg/+fGtrpoZCXJ4L6
5u7uuiaOsk33mlokdoAOlV0s4cvqYW59wXI8+b7aPTUpueF+a8sfGU6a+oU/Dwwj/0CMPIemXrMp
MB9kcoJZkMtmt/MKMiHOiCCTbJbYYxYYpWJ90jfh6LFak2C9/WKm6exavnzFnP/ty+3pQeI532Fn
BsPVAyMZGjWziWlKe08XZ2RxMcIfXv/Pg0gpMOF9sxAAlolnp1oOYaVe4upAF6B+z47h2JLtzc3j
UqbDU4ubhVLt+p6Xf31xVikfkzWACYflV/Xk0BCSMauXn6xodzE1ZZq4MQkQVF0I5UenxOZgucEd
wiZlTXMqqxF1xXtFcsz6YZuuBygkM4ipg/r+6enh5tJkTBawGerIGyA+Pr+8vrDZDmtdBLbIcFN/
PqMkVrP75TMNdx5IfHeQ1MwN2R1tfHdzfnJQjx3StK/BOgDfNMOKa58V7vrq6kYsZG8Naud2nj/l
2yyh0ld7K5nxX+gCz4JpWr15/vr969P1SWFjzub8eKkOn4Xd4MT85n715kkAPTIq0Xm3MuaRQQ00
lMgYPiPWwaMzy1vEJV5jEDA1XbIEOsSzhFPq8Bh77gYm45fnB+Q0n1mMlkWG0xyZNs6oRXBL7QSP
wC5JWHaBhzQXMvwpbGIqSBMVTSCmTnMlua+Wk9jndaouswLrC1YyR0VcbUXW4EgBMW6ksyFPiKxu
rJ/UUPDIMagfRQe+N3VtS22Lr8AHwjQF0c7ktHKQJRdZZLmZvBn85do1JgkPqMimfI4Ly6FE4Igo
+cgp4fdWzfu5NfQn5nB5ZbfII7IQC4BG8S7Ozy+u8qdsw+toYuIGeepqHUTM/0z3Pw9OLG4dYJp+
k2la2l2dgfvkqdhdKyOmC5sHp/iyvn/DnfaEjclIt9ekNCmbthT/zPbo8ORiJl+qKcpKRisLe/x1
mxm89du7ch6zxfEFd9z12VEOTWBLOJZdcA2Wtg4ql8g2lcqsmTfWVldWcZ/jAtvd3Yago7LSUQmL
Yhy+3ylTI8kbMzWHYWJU3ScAIATn+AC3LhsXeCeRggpxbZUjG319WD8YiemhYDBII3iohTSRHiht
DXbkbYel614RVQmlHerQ/YWy57h1MBKuCZPJIeMnpVsI7wdAh3YkpBmNqIp3zAI3tRKDqUHEN/Ee
UeLdFVyN01NTTekk5kgnwT6BkvJOGd80ArbHau++Fdr8jChkD2v3uKNeH85TmKZ+iIMdMv79t9+M
LXt3DQ3RXhMbHG4bqg+qA6ubdWlFjIOnuyuWo7lNUlItkKKATFXkBWDCvH9CTTxcVU0TKLoa2bMF
2nHt9vEZojYBrXivZ6en2Yy0fZSNteV52z6QmCYs2l1M7bVqYdj9vjRmhonxdi4YaM8P6KTibpbs
C2wDs9eDFChK+PiAxZ70vlk/qaGQzvZiKnXieMnYQCRNsNl4ZVl3gmsnuvDX16fbM9uiMaYlVeG8
4yGKJqXL0+MCQC6wSyogVzSTa7p6erg+PVSMm5nQSA33lDeYndVpJbkbbUnOo18m+Bu71u02S9NW
6yam2HS2gnr9/o0VVDG7NJnMHeUMJob4Fl6Cl19//x0W4hd7TdD+eU3a0tYmHNvPTPnTy9kDhQYQ
ZHXFSmmLrBnTk7AzxjUmV3EA6I8vThMo3ZvzDmCPaHsM4UZ+sbgWaJAjCoQP+/vz2mE1/5WZB8mK
dlemzg5KdF/JAKut2bVdZBqzxQaT+ORQDiYmcMAvyJte2LOcC3K1ufSLaaGQf8DE1KA2jfDyeKuM
CTvsxSnAQnfKEBR8da8N7we3R+M8tVKmpHy0ez4+Cv38JgmWlBVKQM7M4+6zae4JatzeJrZJ3aiV
nPaLEg+DZpBUZ5L11lRnEAy0xx0b/ibe6au9J6duob+aK10+Mm1/uTtjBUX0iE8N8F5NN9w0Ezkx
hdT969enWwzxnHtNiKCjNEiZQroulJ2+YV7PQ6wR30FMMrEAZpc2ckRhPXyBkn1zdri9Mi3OtUKy
ZY+c3jx+0UTGvAkbR/wW+HwwrGAFiWkBRJgHSYtGU1Pnrpn2SXZfpAfLdBjP8UH1+gHj+u7ihBwG
4pOTw07cJRIbsjepDDbaNoYLwbzSAxRNYopG+O3b8/0l621y5DBSR4aRJLGQAfH68cXoQ4fby9Mj
tlNiytRx3tGYzOx4U/DkeyCHQH9la++Ed8OMVdPeTsR31/YNprSO2BE3vg9PSmviSF4Ff4PgEZPS
Xqt1fiNSiOKdrOVPWOgjprfV/cy8hYy+Vyn6W2OI37/8iph+f7m/rBzgXUbn6TV5LqPTINuHZ4jb
F0UG5DN48eGZ8NagsUDzwTXOQvkM2u3ry8NlubBhq2I5scweQU89wdvaWZ1Fd8IWFKdXokoKa8fU
kpgmLNpVmQJJ8saEwADKNHdM3AMmi3EgjU/uYh6MLiYLjkSGYkZipKPY0kLh/FgNjcC89fp4bVqR
XViTN0AkYQ2ZyCBjij+E+3vdlsLmA5EyLZ5ePzw93cElZlnLs0CxEpCk3MPbvK2/PiP6rKDBPkoI
JTmFVaUL0qHp5P3y6Sn+apeG1/7C3+QOjoSCf3usFmuh9aNmhNHZ9cLJtRZBzzeVveQL/cg2RZua
mP6GowDrhg0XZnong3QBl6lMo/V8+fKewGpxrrX8l7zh9RcK0HbgBWQKKvBK7MAZhoeSVSCmw1PL
20dIANJtShaFhJZVLXE1RXh3GGnDJGHROgJapTdf7k+IaeLGTKRZ2exXrx+/vDCWjgm5nRDPBHaO
PSNEcsu8aGwuxLQnKDRfNCb9X39Dmd7WjvNoRY12MBCI8t1Cbb8ydXpzerC1aKaTDSTgL5m+ZK7a
WWXZqd17B6RWtwvEF2mqe7w5ldE3HM36CBzzhSuoZf8k2qRYKmGzRUnN9TdjeNRh1YceqzW10fQF
McWRs1Go3Dx/+/71+bpSWJ8dlendVKrDl4Y2lW362/cvek0b2hbEWPEw0En1j2mRCJYXm9OdVpR8
yebScGdDXGtli3H58nBR2l0Tq+CjiemOxPSF12JcAyUCpIpqiajFTWiDVkyykhS1rqiKXa4p/h/9
gFZI0ZgtoEbYHBGjHDfRVWXf9rfFxbXLETyZ/DHuIH8hTD1BYevJujb9/uv3l4cL2zGQvDFuhQYg
alL2dEyjZlhiGkwnQjNklWA6PWB9WsYnSameUPVwkK1IwbMCvDs/zjV7eiJgzK7SBs3uHkwVv33Q
wK1VQnqs1tqM/y6cJaZymyKmuE3zJqaJ/FExbXr38v03JiJRVZdkgwlXXTYY/SL8QsoUnMxXYlaT
7wtyahYb+lZBLk/XlT0sD0KteKlSkRKB5/vzklJYoISdeJuA2x2cZH1OWJSOc1sqeh3R9I9rL9Km
Ce5rqy2bKR5wp9lLZqeZoVR/TTZbYMBpkkXnIRK4ENJCwSQc06bSJ6i9beKAWJTpVEb1SCCi18XN
eI02vRnrKFomawbSOdpS6t78fULRX5rM8VTsVxBjHC0nBRkLLbwVdwMVnF/NbOEprR+4Y/1sL1z2
J2mydNXaNYaYRt79L15M16RNexDTX7FsNTFrrxNJcg/J/7UI93RWFvIyMR0BixLRWAFiZ7LVRMym
mWJ2EV+41hueYShPVUXOZzx0pgjqzVsrNvcmK9qwnGQYN19mZSGqzjYVs7HrfZ2byPY3mCk008Z3
KW1E2OQv6wf9z5xv/ojHdFAwCXsxdf5tlGkpj3VhXg6HgORhYBSXgzHdvj5hvtlYx1Fr+9m4S7BK
biXdWFzS7P7COh2ZXMjIn0IBmEcZW0O3SoBeJJPeJIR2cttjaDtF006o4r/1WC3eBJ8jMd2v3tbF
lPk2vZhSm70BGeAeu+hGToK0Xr991jq+HQHLEJhYyOhtE4x1f368szIN+RFLrmH3YYztbpBKG8PP
zXMmqe42NGDOb28ivleULvvl60AUMih/A5ct+Mxeltugbm++15jrnLzORJHJDWSqKFqA2LNpoJrm
lgL3829qKCQS1kPbhmElj0JgnwmeSGPxIp8NM4qexY11Z5yyAajOHGij0AaSgjHF/SceyC7i0sa0
MiBekwkBFWE2Le1Gb9D/a/pa3P9pxffIuG0ompai8a89Vos30V5M02tTDXG0oGlKw66uKLlD3Wxk
faRlfBsCljQBCzkRC4jGEkvLG6efpQjy5Qs8qnKcHu5mlme1tLXll012rjtutCUsCkOJ4wV0mBCB
bvVL7rPomBangJLcV0TG6RWbxYnIvTjOOVda0yuuK37NywgS829qKGyTVb6/g7NblpnYRSi9ifqu
vVDwY31z/5Rtb8Z67XCbxZCmJBxm2xJe6mErmPNZPtPoIsaMBDz7RMK90Aft7zQ8pzFp0fB2wOng
Jc1psbccK9fyscdqza200aY92KbCjj26m+rBpq0u4yPRe7x2S9idhoIUZT0vln8aaQIZUKJpmXFq
xAKMU5lVkftG1B9IkQszk6NyZrklvhcI58JOUNRQs4AgH1an0Dq75gkDnLT4DG1oJruv85PY8LJZ
/LDD3oiTVLNtZpiWU0OB1sSB6cUUvf14hb9pdkzKtPE+vZ1cMOMUs0BTEvpWLjANJJBVBBH+gdVF
usrOkrtmtBMFQ9/Wry8MtZ2V9gw5gy7yoraPCmw8TONTj9UaDfDJq6FoCdXjSh8xJVkKCyhPW4lj
Z28Srh+OWZxNd87srDs8/MPEJk/UsqjZbg1lqwI8VXKWYP+zzUfIrQVNuQDK+pRnDWA2dC3q5iBi
LSyqcDN2WcSbEdjlCWM1kqAxJxkbWrYgppimsMvqTscmoB3WLCZ7ggLGWExMX2SaQr0YxRaI6W0b
qoyC8iUxbXV2xmcW8n6e+vaN2azCVq6281eia5WICxj9+PeBXtLNjNCeyCmBi7yotvho7WH77z1W
a2qMvtlK3xxS8puapDV1v6l80xdN1o0h/nBZysuR1FRZRcTAwuxEknmTxAY03MdRaxotZkFJLWsN
Ze9bDhw5S9jmY8PfEq7C2N8jaIqIVUVrmkPBr6FkNnQvCmTM6MrcTjyWi6tTbJ0uAgfFZJnAJk56
X+sc7DrXuafr6rtO596hALAmMcVnZ+ZFMyuYrvUNozhZQ0lMUbishgf62DySw/H6GSoA6vQc0k9h
N7fTuHK7RKad1LR9hRy/I6a2IIzs7EQzvnu/cfM8RbVIOPSvKTvc++oGu1A3VdaHSXl8dYeUtKmG
uMOuaf1lkjzumD1mU7V/k1JLet9mV2HkOjveqbX5tRwb/pApRT8iTzFBUy6AMor0RaNI/CxUqFtR
+oumhCCcLyqsUJFu7iK87uhAwQN2yKEKdb+vdc4ZjH42ec9i+jegkO+kMemzR0LAGuT15klJEDjT
l6A2zFfWczjHEFM3kEQO+v7ySBiKMU0Po0ukUyWBFmnlKy3b8rV5ADQEpm5npxO3HqvF7stmqSaF
EyKhtFmqeUvaLjaZNAq3foq/JrBzA7EVO0cUhJ2C+eqwa1G4ajWaPcV6BauaN/J4Ny45MCmsSQD7
9CSmKmTJAzhIkKOiMH3JqRl+2i58tyirbXxfU0sZpUewoEGFrOhSdB35MJ2Xx6zTro3Z2IB1YAE6
zmC02SRumscg4xGNeNAzFNHE9Y6Y4sBj1+7eG/h4QAf7+uVNxc8ichBOQ2IkoO0T0du4zkACTjVL
LFwB+BS7RG8gc7FeJf7YYzXXvlvhrO6yxv76/fsLtiP+iKYV5DvP0SKmnYa4222XmGK+aiZ66/Bq
KHXnkdIq1ZGkRK7SFl1F3F3kVNx44m+K+ez60izJ2DTxg5uJTPeiMP4wDtjhVnCVhQ0qFEjXDYcJ
VeHEuOgMXEfdG6t7WGFBfrF9dHF1W5eHdfxM4RtHoScoEmjTX+qczK/s1Ni+dySmxmH747fvr086
T+GSEJ3YRQCfQvAVgCGO1JtlcL0Lf9mHukGD3f39+6v5I6bqTK4uj5VcTLcPccJITDGY2rGuNVqg
FogBY47TIy+mcjUqGm59Z19Be4pPQVCJv4VpqXwbhBV7NzPeyQRFNXdKTIkjaBVTol7IPOxYoUhz
gsaslPSXdQ66Rym3CiupUxiZF9NeoUgopovOccoyQGI6PtiPNl0U6+IVclAHMVWgqYvaUjTMGjq4
yfXbRQr+G3/2Bg0zxYPEVFDjxuioEZofKYWYupmoi5gaUSsupnKJk3hBSx5l1kZQOa1KkgoluEqk
r9z9npKLOk1S1E3ni+RBLJ9GoeoWrs4JCGpRAaBGG0jSGPtL2idz02xiMe0NiiS2KdoUE8T8+7hI
m8S0hpi6Sf/mzaTP9G9RkETsE9ubWTIWZW8ze7N8/HnfbIjbcGNbnk19baQk5p6kFtMnt/xsM+lH
JrK0KXZ83QEp4fs8SKTD8sZ2AdFS3OqjIo6IEnCYRmkaTE67FmWHUJEEMChEqi+f1C9O6CK0infk
4wWT3NeWeD2KaVooEoqpGRWauJj05bRpaNMXEateHgiusCWUHZgc+98x12ERBGBdJTX6/jwx7NaS
uYLG2ac81W6plvod9nTbNZReTG352W4J5SZ9+IQS07toCSVmgOQFTuT0/AphFEqfYOf/seq/hRcs
pjQubLe1l6Coix6EQbHCgRf5QvzKKwPTEsw4Z0UkaMw4XPFJv5zENq0vcTooBG//tEKRREyNi8CG
U+sSSpM+WuhXZsubWplcPE0OKbmmCN7LEVFFwqtFmMD4FDssA9tJwX/lN+c4FeGUpT68ZklI+12I
t4+TXEyZifwQN4dUk2tV7bqnkHvPxNQt5Ez6JKdKmDgyMU3YTnb3gBQKV3YGoEWriN4JC8K2lxMU
lVNU9FZyhJEScH0jdq2vcXqs2NpuszpBY0Nwaj1xu2F4t1kfeuC8bdoTFCkcUtEwYLVqDim30sfR
Ii10d14+yCnssc21wpE1pKYaA6Nk2/VvBeI/94vtU0IuI8rEG6e7thZPsmObSExjXhi/v9TGL2sO
KReG/QoxOnKLaUxLobIL3z+EoCrzP9llqucuXtoi0qH012PMuhfFMyAGsZJXkuxSWVjdNTfncpHC
HfKb1Unu28djKWOM2B6dvW11Mf03oEjmNzX3vttxZhkgYkTkN2WytPj2KilRFK3X2CyNNk35d2qS
3J/Jt+v/c0L5tmW3hhI3gdBS8fdx8LeQGtpUcgZ2MjElRZU57rQNWhfAZgvdN2SR1CJIRJsMbuox
xWaCCknCcnUpEpINBQVF4D+BYBGtrhMUFdWdhNZQlZU7OHZBXbbgM3Nwqc/dG+s3r6TxQYzTsLfx
zt5IrJM9QNE06Uc7KVG37Q0536LbLGXX0/kd+glhgjtoaRi+vcL82YPyT5hoxDuJ/ztMYFCUbfrt
O/9rf4nA04bfN3lOYdY4mk8H8wQt46/mXahOWyN+f0mbpVidENDaRK425kPxeORd9es450jmfsz8
Ei6l9FziWI1j4vuQUwKriJByG7RJi2rfUTEZBJspFXvj6ldgjCO0+FfS9b7mlSSdBptn0STwzp6+
9o3djlAPUMTF1O/p45CJb8NEhpPZ97AhbaOqnz39MQsikqdPXIB1km268ClH5Iv/vx6089fKZLu7
q3dyWYqxwFrfCCTyyjh7r7WG3pzxJz0zv76n32lrhOb73aaycHJ7ceDbPAbM8jCGlKO44YB03lW/
32F3laBquoZ2tpk/Uvzfq7HN4zFmzkYwme5YVOx/SSpXnBWt7z5mpd7pbvcdImPzOLEP3qRurPzq
LegDrdhl9AbbX08PRQtDyvEhmxhScX1jrEpTCH0KPnd8lBcnpkrWEWNFq9t2KWTHgnYS0UibOvjf
+IIms1gOudu+1Sn4BIq0saNBOyLJWLTPLw3qSQcxdaSBCCdRSW0bqtl9LIQds9Q4j/BWow07iant
MenOkj7sypHx2SXSStkRVp4wH+1HJCxKvjE31qJAC/8vP0qePOoJGhtGTIkrZVcCnqyRGmx4xXWc
2da6HRcjti4yKaFo0KI93xTuRfNuYfw9RuYVJT4ZKRGKJKs8o/tqB9VYkO6ZWv8fA+C/IX2J76EJ
l91il+BUHn6lIqjn3o/emZqTqEhSCNzmHBnHc++mTcXWlWEvLrDtNMvh1Ywv7Yo3ongco5gbIc5v
2Am02GW3V25Qsaag9LyKil0X6VhB/6TJijbVc7g1/dS5sZGBfvZUWX8aT9YmopYzMmnIdLcpKgiC
YtX2BAUj2e3ps1oTe7/Ywt7XUBc7w4JM6m7TAcU92mb1meILiCn0oScywN9c/rfEovPfLCjPqUts
gyCZ04KwLkXxKka2uTNenZEGA2PbYpK67uBJTCWCLme6uUSV58A8c/UZ3ch1LioSg9O9bbd8N7Wn
AR9ByiMoUyfZEYjvY9Y3Gq941j5GMEHR+LojarauQg15fo2UTFSg/X0JoSU7k+PG69g3YqEsdDty
O6ohG9ifZfbKx0AMcW9QxMQU3ui9GZlRLBRAciNRxHCAmwGiFZQlAyNkj/grRcwQv2PsfRdc7t5s
85i0PvPI/03pS34v6Tuny8x1imOFuC7SqVu0ud6+vSr+NeNwcHhsYhLPhUXDCANPZOs46QtfFg7O
frNppx4v5WWAErw+9LlFjRGfeZRzqTfsnhiRkcmk8jyFnQJMAgfs2Ih52S/dLnuze9G6V6AjQu4u
iRpDTEVAMiFg9+ziGG9ePGRRE71OJyTxhWXPMFZdb1A4bSo/vWIroWBnFR0ZRZbCaDBurg+A1g6J
zTIfGdZaQ1nUrqIniCyNP2HdcuZJ7bLX3RGav/APmi6izB3yASNKFTLMzHOqgab2KFJWsz1HvLDU
nl9cWtBJlS5xVxcxrRunJVlHNp63Pb5eAQKk9i/XdpT2hGD366riMy1y0ZkYWBhagVNcWk64E0Ws
iN5n06YWf2TRxZ9ZtXYr2nBedYRcmkmmTffGRuTvcUIAqZgBXt3f0nZrFACu51c+EmKuxpVMS1R6
RZmkhIJlAv22Sd9vJ2m4kwnWsnIYMjbJWICoCyJ3oZHiqUJOMEtD4dyWSYAnJMe+pp9ITUhENcb9
8Z0/qD7l7D5NRoRq68id79IKZEKyk3VJfmMZdAjydGdl4bhc5TynDc79JW22C1uU3xAI2nJ1Ga22
RHMnpeCSMtfdkgUy2xAAHnzk4zPL2f2KxTbafKa8MiCMAJOCh9OmonPlGPAYeFq2mDb1N1XID6Fp
SYom2GCTlCZrjPt+tlAjSyfBMZp35yU4VpZOg87x4s01ManD3NxpQpSe6gEKpuiYmJK5g/0kopp8
jiMzJ0heMuGGOt4u8zyhNWVbmTEgux9b3lIJkPCD81+w2QDYXTypxTj52FrEt+MQ/gv/YOp0dHZ1
R5kvXr9xTgQZu5SwjFAO5YKSa1F5u8Ysb5eiMwq5TcJotaPTddJ3zlVFp/tkEYoag+ExrjQg5Opj
PaZTeJa1drecdpgc2eWpEaxNk8iR8YlJNkfk6mPAaMSzcSq1IdtUAbu2uStxITi3e9G2QZPN2AMH
IyFRYxa4abM+yRiQDpLbHBK5yUzjAozd7LPAcWZrjGvNTj7TmVN5yaGQseO1aZQH6YaMcZs6ycfu
ZSCuMNSvFPTollgakoipmyt35RrRXEVsaT19knmiUEEud9wo8abK9dPGxdOM0F/zDQwUVKFEQppI
SXOKnFYOC5xnRAJEjiRjqwYJcFkQdznRqXTEaRnK1/opiZjKc+oDNbHiORL19IhAZmXkYwgoIZ9o
JZuF4zOSHZMrymU3cdOV8hdgYywu2DGHGjBKcEZOA8vNRZYOLAQ7eIXtoIRFu1MpmVwS39eFa7lU
Z2xMKOmFUr25LHmkyeNEOx27lsuRkFhhVmjXURcrmwoKWTt1MX397Q9OCleus+OCBdpaBsjxKRJA
7pX1As3x5FKWSeIYdD5nIGmu2LhzT6ijNIFTexy8A1QQ8ffEm7bkKv1rBLLDXYUBksTBOcQXOjnl
tPTyQR7GzLLylDJpkfeWo/E4FOAklvw4iZi6tb5LHOkymCrDpuU3tRygUzPs1Gf3jtn/JNkyKGLe
wXqyyHTSunDcVsYfczjJeCG6fnJmgbMOXBZKpZNUyp5+3KmJihqf4N05Tco04X1lmSgfGymaXJi7
je8i51uRvHVqSgeDLnFWW+HgsLifMycfk4fPoZkKClvURdpUYmonhV+dHuvMUOU31Z047qdEklXS
mrPAirYSVRN3DOkOfAbWJ2bKYi7DsXpTOlZXO8akmLW8xoSbLqGdzWPeQVL+2p/pipbPeCMrktOv
mFlKzl3iiLhtnRC6wQGXWR2NZ4cCKpV8gQz5ybQpvhJTp5YHVhlMOcNA2aI5gdAyKi+vivekhNyS
0islLHZLUa2VxnSQFEbG7rZLLj3HKbIct6j8xuje50eXDBWCBYdMJipquTvfBVuvNeF9/WCy9eeR
lxCyCSj4dX11eVkpnLO5vcNypXpyzFEmZkIreCUtFGzZxbTpi4kp4SJ3qBKfLdoFMZdr2pqTAYqJ
bLk3bZXk1Snn0CufNel7OVCLY/XI1T03O6tjeXWAbCa7vcMBmwqt1R7suyP5Xfz+g3+0mUEBl9uS
0ycSD7yS1VkHh5SOivscP8pJDsUjDnjRKUQk12faNhgi25RUBMrm1ibcUQ9tg8Bn1caeJKWuDg/e
V376za2tbQ55hPOkrNrc8oyWXTiSeZ6otb0nK6NI8a3MxjrkO+l0L9V3Psm8UUCSFW2OKGyDafS0
Se4rnr+EgGT6liFAmgzh4dSkPOxNJcTX7HNOZEB537nj8bZHCcaTQ4HQNMSU5Id/kPH4G3lgCLbR
cU15uKK7AvECKWWZZDOSc05L3Ny4m8VOIiG3Ap5Ivs+5UrnspuAE0AzvgDM3imJFb+CoYA/2xxRT
Q4E8l/Oc/Hdyfqsgw1fMbYKOOJKEw54UKczZf/4wHXjzBziV5HeRbWrUC4mp0sG0RuWamEqd6lXm
mdl15qUozbVKdNrHcdlTnR95wyTlUJADZrxbos6v54oyMziw8OiAo2rz+YJ0OvF7j0+UrypzF8oU
Z8FEsqLN27QdxDRNY1qicEwIExHK6uWFzumYFs4F4qiV0okdSasDzPac419BLqmhMFmLbFPLH88x
B8+E2hB9x1GOnH7HwTmAqBN3NFlVLYdpxMH3Ogh4SMhNEXC7PueMSvQPcAKoToWhPoeekn4aZ2HE
i2wDzl/8k1kwSvC3tr3PqSwkb0AxfNHBJHecvUh88LViutyBg6jCQ6/yAN0OK6pePTwxAXfK22/j
WUliWSfJAgUpd3YShyfp6Msr4hofGRQ6vMBFysv0lyGC7O0eVnSuq2KViKUnLqSik4x0ShhHTRxp
vwzjA89rsqJdlanT/ckbs+fU8X47ReSUVR3TqjpHlHGNw5o0+yBMVU0/9QMFUkMhlejElHRd0PDR
pU8cbnRLPCxHOXKvc46FElccFaDk+rtNx5eprj+5SnHkjG+iS4n3FpwlHbGrA6wINPVnzP7AYmqb
bZ9Yhui8gCMdFqcuC/Onx0eOxONYPLuQ2kud2ehjhsx8nGPj8oKD2pTZka14+TNaBh3jWbbvzDLM
Jjvi60mBzJxExwCI5J/DyRTZKSn1OQmlpsZwkxVParxs/0I4Xk+vngciYr8eZCKtnrBotI/Z8oiN
r3qpSe9rW45acrF9u86Dnus8IRuFdzzwDSJ6d8cnTrjZQ03ZESFuFy0dFDxcTExtC+aRie5CZ4cj
q7ruGOga/wq9QYlEnAzrlo0kF8/NkLfwXKGPfF+cc124E0yvdRSyLOgfeNIHB0RJu+U6ffXABxsL
crqOUHG58xvtBNyc/MqK6IQhJc4Px1tcXV+RU7+ZU9f06nF56ei1XQmdpIzLH+xpJ3wyvE+Jf1DD
Xkp5MXJkLSHa1XNTSvbm/bvnXMgaSp3ysj00lSYr2t0nqDkyTWMSAg3wBYK0ObKUiEIDTN2zo0sV
/19it8SCYcxPnxYK4RgXU46Wfbq9QBly8iZKVGekcmQpt1XELef9cGTpdBTI6OXUx3Nv7Nir5eRO
YS9lXL84co6gcn8s0I9qmwoIJ6c6y5rMNTprXAiYPJlE6TBjmTQ6dnvRqzytH0amLOq9dmZnCY42
Jxo2lBzK9nIIuOcA6NqFCwtH1XCBllouy1FLQLOXUtPvOsJwJVuwY5XtYE6nOkj9wBFp7sBosdIY
LnbaYZKib1R99Ij1f2VtJLyvNeaU1Qh+Sz0pBomkQEJK1+o9W4OMbKGFlAY0hmwKKByAniFlWbY4
xsTOMcas12vyp/lqRBxzeJZJaTzszu6pOPK1bOGQ8FyOx3VImqBqUuNoTiWTyVhyorfzYR2cv/6D
4LZwNlyVWeKDyxzUznygI60td80ZbhUWiIRf4lxznAe/zFlD9o6P2LdaZOOjrTfDvZzBMd7lZi5+
5LxathPdi/hIVuYa6SGcAtEOIIdGsV7maFNmJ7tUwZ9S76VaxIuERVsNkre4S3GlauwfsmnMb6tz
2Ij/d7OoS/hjZ9XTM/YnjcFrLlDt96aBwoERsXzEdDo73sttcz4hh/jpYFRLL+QkbWtV+12WDKbR
N8mpgsPnLI6cg/9cjoIr8GTm18mdZNDKb28QWevURKPqD/fJZIlgY/jxeKU5NhUfFAa2rpNy6ejw
oJDL4m5jC1XkKW+XMd+RlIRo4l06qTxh7adV17a2RReVDI+tLJnuujja9Ej+WXmcxx0nwrlDbNgM
UIOoEk53dc+C2+HEKuTYI3PDxT2IJt5ERbvCnua+rjGEgNsPj7PvIGc+y2brGqixnM7jolycmZCU
6kk1bTmZSQFFi5jCdeQst8zaqm24uNvpZoeckkYMt+5lryfWVbun4sgtPNe/WQc/FfH38W43yB1L
9POPulla740AlEIlc/Xswgoe3x1i2eU1xRO0u4OfDZfwLJuccE2dlKJHpBjo+/rGul5G5xBv93Lw
whN7rP0sWt7fPziwhI24lTnWccaRA9271DPpaWBUsJfKCWCc/6lEj40KS3PwAqLhkrxovbOdP6Rv
zOHGLi5929hyT6qe5XFOrjP82HhXxKo3OHqAImabWvJDhSquLNhWh7+d3YwDcKGusScbn/Gto+7V
sqPMqXqcvhmhaXD6d7vsnvOHl1Ib6BZsLFKp9t+WOcSWHajMBkLICaNzM+KiGL2voRjwBY2KAzTX
JcTbjwGUNQwWRcmzs6VLO6FIv46N1GKoIaVOTj+JUqIzXOFvNFVQhlNRs+saink/SdHO4ln/i0ld
qsboHEyvAQ4MnJ5b5Emtb+xGrOpMWrbPReho9Kw3KCLbFAKJnRCBVGmXk9vxhnhHnBBLmD0TUtO9
Yp1yceTiGTg0IzjhxSwv6vhK95wGaL3aj/nBEDSSJJQQUHCx7Api54RRS07v8t77bQq9Hkhvlsje
HczIy+jUs+jtiGulluddMnFONoVlLcJU/FWqEfcwYrnyLNNtKrjTZlIW7fR4jd9T3DeqFOvbJAfW
WtcYubx7dyBmTEjrjwtwyaHAYI5sU+iL4l/PTYyI3OKB0QGxEjQOx3QzXfRk9X/dI0Zo1nO6z8/r
zFP4sFBR/CxZr/LjfjAT3/EPxZyJYtkVxK7jLywEivEWySJ9R41A9eQkEC9nnftGYcwy2NU6clRH
NHBAg05m4MgBn0y/dSQbtNY+cfXtKtQfJJJpsU67Fe38hNFfUtzXV2n0TadP6PgJ65nevQ2/lp41
iieDAgUfF1NI+OKWG2HMelu/WXMId9Qf+9fuqbdlWQocmsJf/D2xAfWcDZXfVPUH/CJBxSqE2gmB
PQpmVxC7iPFohZiQ8vQUFkddl2bslrfR0r2oaWt5wB14Y1xciKTtK8eeRZSz+sE4rkJjuLgniR67
W9GWx2rzNcV9o9q+irE37UnVMxdN0IKZaqSEolVMOV1LpGxQF1mU2/mb6QU1oRI9nf3bpldiE3d6
t011f7wv9FOS2ghmF33WyN6Gd6RJ3YO7orguGYnvC6nKx1o20ZZ0S0Rbpb8BStsa7SukKNpov9On
9I29rWGowU7gL29v87b4O1C8FVNRx8XAR594LdFGiby5a5ubasTr5bZ5t2+q/2g/0B0kVbLqL33R
j2/xtl+jPyfoh8rHWxZA1nSnuikqpCja6W6N33tozHWtCTW10miz+VPyO7QT02Et6GNIdoHR3/rt
Pa0R/dzxOZuf+sf6Zg/e/L9OD+hLdfrzm9+jVj2w+vqmTNMPKSqkKNp0i7Zf0jcW1Wj827bh+o9R
uS5QtBdTeGRRff9vvd33PkR1uGej/nsVfoa/0an/yGNGYCVvPEWNFEW73z99Y75G96Zdie436CSm
9mpc9aQ3i8pFN/3PvN3oLuHf/yUE3hXT/yUgQl9/ZASCmP7Ibyc8m0cgiGkQhZ8AAS+mSqX6XjzP
T9CT8Ih/YwRMTMfnN/eq18TzkJDPHZzVeWf6b4xF6NoPi4DEdICMvwWimB8IyrM0W23ieX7YDoQH
+19AADHlqG6lVzm7urk+Lxd0knvXKNn/BWRCH38gBNi4sxRHWVIUnNcqxR0SmRHPEyb9H+gdhUcR
w4cstBML67mD4zIHC2dcAqP/0M5LADwg0BsCZpyOzixldvJ7SohI4qwO8Ty9tR9qBQT+BAQsnoc8
sItrG5uE5MxNErQU5vw/AdjQxJ+JgGZ9Al4Jp1xYVOCKQgDhjfyZtwhtBQT+bQQUZq1oL44+UIZ0
F6z4b7caGggI/LkIYJ1+0PEHQ3beRGvc2J97r9BaQKBXBCz2R6cg/MBnNvbat1Dvb4MABFEFqeki
4oFvf5uehY78rRAwQRXnPgjp3+q9/u06Eyj3f7tXGjoUEAgIBAQCAgGBgEBAICAQEAgIBAQCAgGB
gEBAICAQEAgIBAQCAgGBgEBAICAQEAgIBAQCAgGBgEBAICAQEAgIBAQCAgGBgEBAICAQEAgIBAQC
AgGBgEBAICAQEAgI/MQI/H87hJyqCmVuZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKMTU4NDYKZW5k
b2JqCjM1IDAgb2JqCjw8IC9MZW5ndGggMzYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggNDcwIC9IZWlnaHQgMzUwIC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRl
cnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K
c3RyZWFtCngB7djXWlQJGoVhKyegSGKBClokE4ioTTC0iAlEBUn2/d/I7Gq7FZywDme+Z77/DNfJ
cr3s2qVXrngu4AIu4AL/CwuUPOoC/+bX5/tfp+wBF/jrV/GfZIs/L5crHnaBcrkg/IW1MK1UqrVa
vV5veLAFCrR6rVqt/Oo6QK3WG612u+MRF2i3mgVs8bxeeFoHqLVGe2ikOzY27vEWGBsdGW4364PH
9SfrALXZGRm7em165rqHW2Bmujc10R1q1avFh/AP1lK52uh0J3s3bvUXFheXPNQCi4sL87dnZ66O
DTVrFx7W4lGtt0YmpucW7z5YXVt75KEWWFt7uHJvuX9jarTT+PmwFm/V4lEd680traz/trX9zIMt
sL218eTh3f7M5HDxsP79ETxQbQ5P3lh48GT75evdN2891AJvdl///nxjbXnuWrddv6BaqbVGpubu
PNp+9XZv/+OBh1rg4/7eu93nT+/3p8c6jR8v1lKpUmt3e7fvP335dv/z4ZEHW+Dwy8f3O1urC9fH
hwYv1u9fggvVent0ur+ysfPh09HxyamHWuDk+Ovn/TfPHi3dnBhqXlLtjE3Pr2693vtyfHp27qEW
ODs9OTx4+2J9+WbxdekX1ZmFh1u7+4cnZ+ffPNQC52enR5/evVi/M/svVbfffDw6Pf/2h4da4Nv5
2dfP718+VhXFFsqqGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUNAyFjVZFsobSqYSBkrCqS
LZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlVw0DIWFUkWyitahgIGauK
ZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa1TAQMlYVyRZKqxoGQsaq
ItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2UVjUMhIxVRbKF0qqGgZCx
qki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUNAyFjVZFsobSqYSBk
rCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlVw0DIWFUkWyitahgI
GauKZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa1TAQMlYVyRZKqxoG
QsaqItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2UVjUMhIxVRbKF0qqG
gZCxqki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUNAyFjVZFsobSq
YSBkrCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlVw0DIWFUkWyit
ahgIGauKZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa1TAQMlYVyRZK
qxoGQsaqItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2UVjUMhIxVRbKF
0qqGgZCxqki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUNAyFjVZFs
obSqYSBkrCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlVw0DIWFUk
WyitahgIGauKZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa1TAQMlYV
yRZKqxoGQsaqItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2UVjUMhIxV
RbKF0qqGgZCxqki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUNAyFj
VZFsobSqYSBkrCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlVw0DI
WFUkWyitahgIGauKZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa1TAQ
MlYVyRZKqxoGQsaqItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2UVjUM
hIxVRbKF0qqGgZCxqki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQLpVUN
AyFjVZFsobSqYSBkrCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZQmlV
w0DIWFUkWyitahgIGauKZAulVQ0DIWNVkWyhtKphIGSsKpItlFY1DISMVUWyhdKqhoGQsapItlBa
1TAQMlYVyRZKqxoGQsaqItlCaVXDQMhYVSRbKK1qGAgZq4pkC6VVDQMhY1WRbKG0qmEgZKwqki2U
VjUMhIxVRbKF0qqGgZCxqki2UFrVMBAyVhXJFkqrGgZCxqoi2UJpVcNAyFhVJFsorWoYCBmrimQL
pVUNAyFjVZFsobSqYSBkrCqSLZRWNQyEjFVFsoXSqoaBkLGqSLZQWtUwEDJWFckWSqsaBkLGqiLZ
QmlVw0DIWFUkWyitahgIGauKZAul/7Pq6tbu/uHJ2fk3D7XA+dnp0ad3L9aXZyeHm9Vy6cqfVypV
6p3R6fnVzdd7X45Pz8491AJnpyeHB2+fry/fnPhFtT3a6z/YePX+4PDr8YmHWuD469Gn/d3ttaUb
E0OXntVau3vt1r0nL3b3Dj5/OfRQC3z5/Gn/3avN1YXr40ONC5/A5VprZGp2eW3z5e77D3v7HmqB
vb0Pb3aePb53e3qs06j8fK+Wq83hievz99c3n/++s/PaQy2ws/PqxfbT1aXZqW6rXin9+LZUrjY6
o9dmF+8/fPzbxuaWh1pgc2PjyaOV5VvTxZelWvlv1SvFl+Baa3i8d3N+6e79lZVVD7XAysqDe3cW
5mYmu+36j9dq8a+bUrlab4+MT83cvHW735/3UAv0+/1bszd6k91Os/bjtfqnaqXWaA+PTlyd6vWm
PdgCvd61qcmxke+of71WB/8TUSpXavVmZ2ikO+oBF+iODHdajVrx+XsBtXizlivVwrXZanvABVqt
ZqNeLT5+L6IWD2upXLhWa7Va3cMtULBVC9NfUQesA9hyxWMuUNgVgoO36eUbuHrkBS57XvqJ/Nf6
f+1+CdAfXMAFXMAF/psL/APeID4vCmVuZHN0cmVhbQplbmRvYmoKMzYgMCBvYmoKMjQ2NQplbmRv
YmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt
YWdlIC9XaWR0aCAxODcgL0hlaWdodCAzMDAgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVy
cG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz
dHJlYW0KeAHtnYea2ziyhcdjd1LOOeecO9jjnd33f6r9D0BKlFqh2VZ7eu8lvxm3JJDgYRFAFQpV
B3/8ERyBBAIJBBIIJBBIIJBAIIFAAoEEAgkEEggkEEggkEAggUACgQQCCQQSCCQQSCCQQCCBQAKB
BAIJBBIIJBBIIJBAIIFAAoEEAgkEEggkEEggkEAggUACgQQCCQQSCCQQSCCQQCCBQAKBBAIJBBII
JBBIIJBAIIFAAoEEAgkEEggkEEggkEAggUACgQT+n0vgy5cvpyVwtvD0Zb+jBGj2OHYzt+zMox27
7D2/ubd687Vc8Oeff37lfz4dXrVX6Lvqw9rOfLd1WxDm85lz3SKAf/367ebm27evr7F7C1Wqp3xr
xe4N3vLXVPx1ezhPcOFKgft2e3d/f3d78w1ce6fvFeq98JQcgr933i9+EfCv377d3DqHleNrQR7c
hotu7h5CkUg4dH/77QDTXiHvhepvbqlY7+egnl/5KuA3t/cPoVCYIxR6uL9HjpckxPN+u3uIxJPJ
RCxssHsweAsjD3fI5O7+4YEP18Uu5Lf34WgskUhyJBLxWCT8AJjzEuKy24doMpPP59Lx8P3NV680
vYWJSOgeuUSisWj44e7mfK2ex7/8UQK6fYgk0tl8oVgsFgr5XCadjEdCd7Tg02/XyDWcyBar1Uoh
E3u49ULyFhYziWg4HIklU+lUPPLwqmldRnjyDEdAuVK13uRoNOq1SqmQ5TavW7Cnki9fvt7cR9PF
WqvdrOaT4Tvvc+4VFtLxaCyeQjL5TCLC6zno0Z5KfX788ufNfSSZrzS7g+FwOBj0e91Oq1EtZpPR
cyLSE4fiuUq7P+g1y+moWsy2yewX5lLxRCpXLFfK+TSvh2f0CfHE6Ubo8WylPZjMF/P5bDqZjEfD
frdZyafOYVczCycL9d5oPOxUs2oxjFTOTfYKa4V0ki5RqdWrxUw8pNezxaKRfvvF7weg3wGhMZit
Npv1Sujn8/l0PGhX8yn7elW/9wbmu8aXcKrYHExnk149nxAkjaccf/zhLew3iplUKlMQ9FLWQldt
9lznX7+ozfnchSZb7kxWT89PmyVin80Xy+VyhixzCZqw0ScWkS4w9wIkw9JdJFVqjWaL2aBZSKpn
fJPOMfh5LhUOZ/PpoFnK0EXz5Wqt4kr9i6px1ZRzjX/0X75+u49lq73Z5vn5aTWjsYwms+V6s5oP
W2WNHAJk1aCVlaMXUQX3kXS5PZov56NWKc3YfodaRR/QDf8U9HS5NZovZkNBT6ayxVK5lHPbIGdI
CUoLbhWgb+wMFA+xXH0wf3x+Ws9GvXa70xvReB7Xs37DCNNWbzSUZCWrxRy3elvt8WK1GHcquSTK
IIw2k1XAo94IOoXLuaAnEol0jmHXGWEkb5QgWiqEAuSa92lZQY/nG4PF49PjYtRtVCvVRmc03zw9
LkGUiYdRgqrdaighv0XB8MPd3UM0A7rlejXt14vZdDKRlDaTVYBAzSsx0FtAjzM45vJZq7sM8LsH
xvo4zxS3mso7tr5R/jvoj+tpr1HK5/KlepeW/7SZ9ev5VCyCGlTtws5NMVtQvNEI0grFMhX6yGY9
H3Vq5WKBgTuXScWjISTvvhKkfgidl0JxOJZIZXJ5dHEmhc46q0NOPMoW+mazHLcruVQimS01eQnP
jwvTTBP0MUcPfpXMQ9EEejFB+4jEgT5dP9FFBp1mo16XNivmUqbZP9jW5EJXgymqwTzQoG7uqCST
L1WqtXqtyiXO2/AOYyfgen92oc83a0GV5kvma+q1TyseJZ/JZLEPnFYKcswWfihwt2gUddCdbl5e
wD5ClfX4r9PU4B0xr8Rp661S1nRTq5J4Jbf3oVgqX641292u9F+9gsLVWLY3BHtBHv/sgT4fNgqp
KMIUIglz3KkW83ksBCmTWEht+A6zpYSsyvlUPJbIVbuzx+9/fX9azaeT8XiCOht0G6Vsgi5La7Ld
tFXOptLYOpgY5Rxiv78Px9OFaqs7GI3GUn8dR/35tRBeQY9EEjvotVKxVGt1uq0agw0DAWZLqlhv
d9uNcpZumav25k9//esn2BdSCPPFYjamw2BxRdWabDct59Io02an264XGURD4Vi6WO8MxtPZdMoT
D/vtuldXHRfxkV9d6Iv9BoPUH5ejdq1UqjZ7w2GPphTFir99iGEz9IeDjtR7KlfrLZ5//vvvv57X
QAf7crVaTHqNYjoRRwAu9HwmV6xjIvVblWwiGomlCrXOcCqlLaNj0GvXy9mE7GZHHe8U4BHAu58c
6MOF203RHnTT+eZxMx+0KqVSrT2cTBwz5UYWV603miJaqfd8rb94+RfQn5bT0RBlNl+t14txt5bX
c7nQK/lsvtwcjCcjClLxOC+rPZwx5E9HA9p6B9OzKOiMYQwERiObZ9iBPP5pC/0RjdRrlO3gOOZJ
Vtgm5SIj5Wg2H/dquTiTnLtQAnNngnqn86HdDfS///V9PR10UWb98VxjJXo4m07nq47UK4VsodIe
YuzInkmaEWy6XC6mw26rUasxxpQ0xjANcQ5rUVzstBZ6c7h8fnlajh2VNJyt1rIEKgUN8uPFAqWT
w8K6pZcWmsMZur9t0NX68+e/fv545AXVKhXa1nix3iwn3Vohm/FAzxV4DIwC7JlsOlOoUeVKVhKi
0ciey2pop/9ySP9ZlYzkj0vb/dVALzRHq5cf3x8X434HQ2A4XaxW83GnVszRSHuTxXLab8g4BHqy
iFEFdHQ/gq3RTX/8eKZXIFo1i/5UYgdiLgdCrjQCyBVBK3umVc5lcrTHGX1i3EUHp9CnRqMyOWcu
FUX9oe/MRF0t30V59K8Lff3j50+w02RH4+l8uZhTsxVRb4IdOfBAH82t2WKgzx5fntfTLhZyIk7z
bo9oags9SR64XujO57x5A4s1agzjJh5lGq/JPAd2Adovk8kYhSft/Tbo481ff9NmH7F6Z8Zgx5xB
lSToid0z0KtSAFK7RXRoOJoqNPoz22KKBdkTHqnrs3mkUr03Xa5pVTKq5S3AHNK0O8Z8BPOyXC6h
8KR2L5k1jtSB/u//aJAT9ulkNOgg80QsxmhwBjqFaiCzXi2LU+A+FM+aH1bTXr10HHq1WCjzeCvG
oTbTQsnWuIDuZRowHWm0Ws0GCs+o1wstZg/6D1QLuKXgqgUMDmnWC9AnEmDHoMBI0JxluVlhL5ux
6bXUq8VihaGXIZQ3pcm4semMVYNtUG91e71et4XaZe5yaQK+g/733z9f1vPxsKdZNbOCGPZuCA3k
lfp9OFliduG29VwVpCvMtpLmghi6qRJWsAO9bDr4tpvaBiPorSHQZXUkQsYFYmZcMmvQuD3N69uN
Sv7t0Efr7z//elnPGGrr1bKsK4yN27sHLBFBZ8JQSDIPsuAWa9nyjDBe6IzKDnS6oKRePtbWq6Xj
0HljqRxS7yB1DDK62Rulntfg+P1lM2N4LheYNWB0o/ZldcskXzLG83ojjLq2SaiNbKHrOcpIHYvQ
zIzM3OMtDQZhmK6oqYecWJlCudaQK0htPWZcB2dHR9Ng8qikJxnoDGoZcGtc1TzNzHU64+Vqoeln
NPQQpu336JmrSddCZ1KyWU27FQzLuzvNPXhHa+nhM91Uw/paNaqVcZdtP8WmLzGDLToOrEsDu4Xe
GC4emSXJxsC0c7QZwtC8ntZLc+5UsvFIOCq3x4KJKyO5aTAMjhg7TKeSkVAoksAymK70GmrFwpFx
XYNjodQw5/De5NrQu7XDo7yezGoyaaaKxgH7pnFdc1PMr1GrrBclJ4DxSRhXC/4KFAiWQAFzMInd
OMbt4UDPMxZunjAgcB4wkiYy+C80epxUSa6q4s1o1m6GAgYDTa71R+qUA2/tW3zCjtQ1XqnT295h
DTd6/m0oic2iMtDksyjxBr6Dl5eNlXpeThC+MYtlXs18gp4pVINGKZeV3XKgkjAEsCKlcvV8nWo+
zQPH4sysmetqpm7MGOMVQXoXlOkfFnodLYEcavm4M17JaJDTE2+ByjZYMa1quVRp9CbG2tk2GGZJ
P55p+lhSjCn4EmgvMr8yxvwyJhcDlmN+GRsmy+PLvGNMqBZz2Uw2m9Xc14wLTGbkl5H1i9F+1HLZ
/Sh4+GHQzcwRqrnYw83OJShPKu4lJMk8ZIKearZ6o4VmdJspI0wKm8VO8OQGaTUarS6WGZhk9KbS
MmjwfvWbSLpQNZ8HTQwuaw0j9umg08DerJTLzMXlohdi57gMHNEyjAjeeD7DGszgsfVCd/xv87Ww
D/v9Ad6lp+8/XtaocSbLWZTnGpPzeT0bD3o9SkFupho4FjJYiBMmJfVSjvldy36mwyQzRTqqTpyO
+t1OG82vqYYdxzVBMsdOuCc/yXHH4M1UaMz0IR259zhiTWNP5GQBrrnTbDKeYA4/Pj9vNM6nE3TL
JkMTLgHmdyqcYSzzepjgxfGoF5iljIbtKoqCPtLjM27MJL05i0Kdai7IRUO0Z6fxJsV/+AxyykaY
KncH/Q5DnHHxu+e4Hv5GfwKmpaafoOOeWMS1fBKXluxKPZYx2vCzLhbzCS1ELoFoIldp9fpdYKWx
CavmM2auRth8tT2QZb3AOzse4UTAVbB3ZxfB2b+OZMuNNkYP7m+5ybcX8FzMRrPlJtNRjGE5LPA/
ICosYmxtjD1Jc8K8XodOmYxYKMBlgfZi3l9ttjBHNKhmijXzOYleC0VTPEnfrXLYa9fkAva9ZgB0
eSjwtjBDNEOjFzrNyXheGp0+s+ahVjw42s2afC0hDNVsCbujiyuo1zeLImZ2n2TR7u4+LM2ulQw5
AZJZZ1UDfYfvCytRVY5oRH2sJufOu162Fd7ZD2oxmG3ZXC6DSA4e3TyYMFTqzRYdSn42hoQS3jCs
HGtkl5iU1mqUmxOwJIx3Dr+HltaYdtJEQjQf+5l5/w1uS1xoRapsczTrlUuLP6fwCx1ywOmqVbuD
WZWc0je4NlM464x1gVrSDAyXtJnfaN2UORnPrXLMj3w2aZW4sahYz8QgQtncMwkyn43HAmMrrHUx
XgRioBfzsLLcdy31FNj93w06Vp3xjuPoPrzeKeXGmBdAlk9ZmtrYZ1ooRqBMhXGuqNzOKrVqaazB
+we53GWm3ADefGbsVhHCMlUaMfB0eiLfyKU0ZXRiApklak9LN49oS+UNj0S1pi5fg+NtkM0nB78c
EADD/lC5xxNPoa3VnqjPAGfY1g21Rm8NFonsDXp/X+L2m6rC8HSMrsMzKJWYQCHbQhI0SygGg0q0
rmKtP57IPr4xgXSZSh0NaW9g9Luw2yqNFFyR+W0ujmSpSweVHiLnu7mTubWAgNk5VVrPfOZH++wW
qK3FLbTPsX8DU+ZeYh7u6I2PYHn9E3WZ43WJflGRBWyezp5qHtL5eFDu1LIttDXYr54yb5XOzx/x
Zwvj2GvxQjtefgzShSqPXRL8FkggkEAggUACgQQCCQQSCCQQSCCQwP9lCezNd/6XHlTAnYne/xJs
sNpJtplev38u/I88M8hxbXxE8sJHPw7IcV19RPLCb0GOA/H6yQsfjZzobvlW5YC8dvLCb4BugzSv
n7zwO6BrqcC6/K+ZvPDhyM16H4kdZU/ygtfdxYj/8RjeeQctVTrQCQjVypXjDbUK1v33nbV/6GUW
OolAbvKCfNWu29M4fOUI/pTC18JTOJ4pbJMXLFzrb5aXHf+71i0+YcMxq5FRVpZM8gJBZ1oZALAW
RdBTCrFwEww+9O2/o3LGdRMv5CQvIGObcaEwRVK+WOnSspcWkz6d3PegRxAw62BKuSDtkBh1m79A
/t7lGMV3iO0XL1GDIcCMpUitnLIixqJ0kpSLApkF5Qox+gTlFy6kwP0ihPde7nZTswqt7BkSADTK
NxqNJqvWPZazFennpB+99y4fcZ2NdyAg0SQvJEnGJIye1IX+QAfx6xMCPPtKgdtPJ/wILD7rNHFJ
MWIaOiZ5QQEOBOwQZGHyDpU2sFBYupMC96m6qnppiOSSjpIXiGFR0IsidB8fTfaeyXhYE5huUuD2
8hf+cS2lXqpMzb6bvKAYOyLwvpPfMycWmIyH5XpNnFi9sM089JPC4LMR+Dnd9FInU9NEDxI82Jlu
vv/4/rScDAg46St9T8GCNkraaCzv8rafm133XEE3mZqKpFMejGLEFXP3siYir16tNboj4sQIwCO1
g5gF6Vg/KQzXRbtXm4FuMjVN3gV5pAb6y/enxbBVLZB+tQ10LCjeiKgHZfC9OYVh72bX/eJCd5Mx
LXQyVdcTxVs6eUHEhpEzSCx2JOozheG6aPdqOwqdqF4CmRVlZ9P3iKVTY88msQ/IpfKTwrB3s+t+
OQpdaZszojsTxEmZ7DWgk72XTyvzzl8Kw3XR7tV2BLrC203KA8nMhLcr21p5v10SJtJkUvlLYdi7
2XW/nIAOVJPyQFJBsthUPoRNqsoRLegrheG6aPdqOwpd2dWjVlF5A0rrJ/Ca8GAFJFup+0lh2LvZ
db+cgO6kctg8t4YLXW3dZwrDddHu1eYDutLDNML4SmHYu9l1v7wZOt00R7os0ZO+Uhiui3avtrdD
VyIG6XU+Uxj2bnbdLz6gw/yg8F0ZMYqLdCMCr4vHR20WOkO3Nb9kw4h6QrYYSUa2m9YHs4XSUU1C
s2M68udNKQw+oPg9VdDDDo2HAuzhHCiTa0xWAzmdBrpSO6bz2bBNFD9htk5QpPxj//BkA+hMNYqk
KJPIUCt4shpqJAGTNW5Sr8fTCUkZqUOPpF85Xfd8O8EjVcAkMuQwsNJOVgO9El4Gm/BOWHpXjDEH
AeXXheK3NqCT7kOqRY9EBrEFkI/qfCF3lOkQOXrFRrffI+ueR3lPcLRfSG8933FmFGwig6hA4k5W
g3ItRIYRxkXQaJFd/9ncGVq/M55ex4WktDsnq0FLHAq3Vy5DpVyAnUWkR59opUAt5t5NZMAvisfR
ZjLEEDoOa8Su3AnlAVxM0n3rq77SeRI72Qpu8gJ+3gc3k8GkCkCqYXInyIdQJ/1EQmeZnbVq6PBs
IoNxrjtfhJz1DVHfkEHg8MxdSWDXqcaus7uJDE7wvyeTQU/mZDl8MqG70Q1WswNul9Ugbcn/uyyH
z9Vc9OYEzxx80LH9Yl7rqx+u87KvVYtBrH9U4d4X7w/XultQTyCBQAKBBAIJBBIIJBBIIJDAcQk4
9tjRwnNlRy/4jT++MiA99z5X5jntn/kIOMz24xFrh2X2Qf4ZnK/vaudGJlucidP+XNpbpkIO4388
OO11pb/lF6E7xdy/V2adpyZI75ME5ck5I1YAQ4xw4MLYLxPqzxT8jmBPMvd7yyzP7acKfkew+Oug
gDnC3O8tEzEGoYWfKPjdCPYEc/9+GWFuitD7PMHvLnXPMeb+vTKxfBEU+RHM/e8cjdQmTjH375cZ
otstx41xSr7znpcuYwS+dIrK7SLNceb+/TLC3KLQJ3mD37c30Hi//fK+D6ri4NhWZH/ffnXdR2Zp
7Dhzv8aeHat/AS5oG9F5ZeZ+IAmb9cPJlaiDb/xm0NpC/WvB65MUI+rIxoMdYe437PcucT+UdqLU
8gS/U7fjB3x1N4+A3vJRSGwd8j67wegupYtT6D6L52RDnXiUud88lkPcr0W9GOSBnuB3iYVb7m72
3tB3qjGqzhuMLjYgQ5hjbmHC/ngTVuA62RwuTbyCjw6Y+73s94JONJgb/K5VD9lshtjnF5n7QQ63
kSqxweiKRrf8+7oHt1BwvRtYr8e8zNzPq3M2JFDciaCL0vbazP2SuSFXEv8/weiZHNHohkxfm8lg
eihSnVgLX8z9xAbs2O+BDpuSBzq18mjSUb/G3G+Rm4oVjW7I9LWbjOH8U3YA90j6Ze7fY7/fNZgr
M/drCH4Qj77i5xuNZptodPHvw+Em4wPytFg655e5H5JssyGBjYs03XSrkmDr5EVegbmf9vJNGUcK
RtdBMLqXf584URZEK76Z+y2PoGXThIsQjv90wQa/I48rMffbyPRsGdrFmdkDhyh6MQXCvy/WaxEF
wtLX6fhi7odiMMWePQ4RqKBDfgq53Tnm/sMNci6P6jR1ItMVEaJdcCCkhynQw78vNUggg2/mfrjE
txTycP6zqQlc/Qp+P8fcr2Xuy4i3Z1hro9gaLZ9eXh5XMygiBx7+fe22Aee+b+b+OuSkLg+7NmQx
DJpu8PtR5n5nhX4L7PIHWRuRFHyeG5dCvtXy8O+Lk1dUpLQfX8z9bZi/XTJzoIusv6Vtik4x92tD
Eb/BKAZ6urwLRj/k35fwfDP3s7ML3NSwzIr0VtBTRC2ZgKsTzP3s42J3ergs7O0ZFroIYG0w+gH/
PrsnWLJjn8z9w3atLILcpQudbR8E3bDeHmPutyrPNfG28M592EJ3g9Hh3ydMx+XfJ6wesvoz9Pds
3XKEud/su1Bt9i0ht6Tu2bHiGHM/KXyGHtFnN2WHI7ObzVH+/RJk9XD5ntx04DhzP3zQzVqtBbWt
uMQ90I8z99+KudA3PaLT1s0eQgSjv+LfN00WBCf2SzjF3D8btOv1o9CPM/e/h2VwCx3q36P8+yUj
9TPQnTB27R+Ab8My90Nz3W40GFNeS/0oc7+sYCzqcy37ddkO+nH+/coB9Lcx9wO902iQLnYc+ivm
fjMR8IncbP8mzvrt1gHw72vett06wIFOk307c7/2ZDkJ/Rhz/69AN9kLW/59s9EULYgRUVsHMML4
Y+5nv4Q3NZgdc7+dgb1uFOd+2TaYV/z70I07/PuC7ou5H+iD1plu+oq5387kfTZ2C12DozYbcvj3
k4Z7Xfz77FalbWBIKPHH3D/pnR4cjzH326xyf9gd6PDvmz3BIMT28u+3KuxFJNvVL3M/G9FUjUry
aFMz7zjB3O/u3nqugRyWudBJqPv+OO+zf4zh36eNGP79Ilz95dYQ0m9/zP2ktxlDYGvDbLXpMeb+
GPzFhm3Yl9gd6D1tfwSnfa9R8fLvKz8KwndtaemPuV/ml91xSemGu3j3E8z97AkrWmh/scAu9MXL
T/ZjoWPu+PeNCpdF45u5H4WE8VOsdQxxvzfe/Qxzv90L5LBVnPm+g262+rLs/GOHfx+ueu2wZnae
8Mfcz8YP7Ohgyfr34t211cUJ5n5CbP3OkmR+9dil7D///vmyYQOfyXS+5d9nfxPm3L6Z+7HKU+yS
Br38mBfgiXe/xNzvR6O6Up8/I3Wgsw/Ajn+fqa641glN98fcr/Rrsfq7ZP3eePfrMfc70LvbHfm0
W9WWf98k7Ppn7scBib8r7pL1e+Pd89dj7nehK9uYvQTZemFEUoOzu552qcHxqT0TfTH3g5ydBdjN
0LL4KFFpF+9+NeZ+C71Mjvfzy+Nywn5PnbYI+g3/vqWqF3bfzP2s2W2J+73x7sq8vhJzvwt9AieA
hu56lU1G4N/PaKA1oel4U9/B3K8kiG2IO3koni/GB3sF5n4Hutkk1mzuok0FXP59uzpg1qT9Mvdj
UJ2Kd8f1Lc/3LzP3G+gmRXepjVTYixJWCS//Pqa0XOp+mfutZ34b0i6w9otdYbBV/hpzv6CT58Wm
iKRysYUtuz2wDGDXNLTkwwF2584qoKVyuDT3KtG6ipZxlHa3u9JcpUItTHm/2GmFU+Venp6fQV24
LKVEoz/WhjVsm6TNI937uVp4e2eDRGsdHBYCj8VhVqIoNOXONFOvyxzeE90ZqCmkTdnDPp17t7f+
ddylIvIYtM3OV0ZMBtiuDt3d4thC5heVq8Qe3nJ7pVuyf6JTqwpfX+IUvumPdVK79Cnab8w2xlcv
b4vjVYm5z674ePkxMLtrjpVe/I1H19JADu8/+8PsdlK/eOEnOEGNneUR1lzgMvp0+VBnBWSWwcxK
FzvtfGTowVkU7yqkxaAu0Q/QirxrL5p33fU6F6m12+gm/87W6yB4fy2Su1jfDEudr4nt++95rSvB
bpWKBu1rVfqb6tEAi3rQn990xyveRqg5rlhjUFUggUACgQQCCQQSCCQQSCCQQCCBQAJvl8B/Afga
EsYKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago3NDYzCmVuZG9iagoyOSAwIG9iago8PCAvTGVu
Z3RoIDMwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEzNjAgL0hl
aWdodCA5NDQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQ
ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHt21mTHnSdhmGy
dUjSgWyAZJGRAMkoCgEVkUSHLYwQlrA63/+LTAfZXKrux1Pr+h9QVJ5fcXAd3Lzdb+WxxzwCBAgQ
IECAAAECBAgQIEDgP1rgmEeAAAEC/4bAv/5fwnf/geMeAQIECEwCf8vmPyf16M+PHz/hESBAgMC/
IXD8+FE8/76oj2p64uTJUwdH77RHgAABAinwqJenTp48cVTUvwvq0WfTo5g+fubsOY8AAQIERoGz
Zx4/SurRZ9SfBPXRh9ODx8+ef+LCxUseAQIECEwCFy88cXj28YOTJ37yCfXoh/2TB2cOn7z89M+e
vXrNI0CAAIFB4OqzP3vq0pOHZw5O/uRH/qOPp6ceP7z41NWf/+LmCy+++JJHgAABAiHw4osv3PzF
jatPXTx8/NTR71C/+4n/0cfT0+cuPH39+Vu//PUrr756xyNAgACBEHj11Vd+/cuXfnH9qQvnTv/4
AfXYsaOPp+evXH3+v1/57Rtv/vEtjwABAgRS4I9vvvH6b24/f/Xy+aMPqN//BvWopwdnn3zmuVuv
vnH3z++8+977HgECBAiEwHvvvvPnt37/yq3nnn7y7E96evzE6XMXn33+V7+7++79v3z40QOPAAEC
BELgow//cv+du7/91fPPXjx38MMvUB/9+vTw0rUXfvPm2x989OlnDz0CBAgQSIHPPvno/v/84Tcv
XL10+Ogb/r99IXXU08cPL9946c5b7334yedffPmVR4AAAQIh8OUXDz/5y7t/vPPS9cuHj76Q+rGn
56/cuPXavfcffPblV19/4xEgQIBACHz91RefffTe3dduXb9y/h97+vPbr927//HDo5z+1SNAgACB
EPjm6y8fPnj/7mu3b/yrnr7+pw8++fwop//nESBAgEAI/PWbrz7/+P691/U0oMwECBAIAT0NIDMB
AgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACB
UUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ
0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSE
ckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwR
IEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQ
CAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJA
TwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMA
MhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwE
CBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIE
RgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFA
T0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMR
yhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJG
gACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBA
IAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgB
PQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8D
yEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADIT
IEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQ
GAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYB
PR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9H
KGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZ
AQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAA
gRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE
9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0N
IDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hM
gACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBA
YBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF
9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0d
oZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhn
BAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQEC
BEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ
0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0
gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAz
AQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAA
gVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU
0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0
hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGc
ESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQI
EAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRC
QE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDT
ADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDM
BAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwEC
BEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFR
QE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDT
EcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRy
RoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEg
QCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAI
AT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBP
A8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAy
EyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQI
EBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRG
AT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBP
RyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHK
GQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaA
AIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAg
BPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9
DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPI
TIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMg
QGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAY
BfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9
HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0co
ZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkB
AgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACB
ENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0
NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0g
MwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyA
AIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBg
FNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0
dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2h
nBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcE
CBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIE
QkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ
0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSA
zAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMB
AgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACB
UUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ
0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSE
ckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwR
IEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQ
CAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJA
TwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMA
MhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwE
CBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIE
RgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFA
T0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMR
yhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJG
gACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBA
IAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgB
PQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8D
yEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADIT
IEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQ
GAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYB
PR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9H
KGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZ
AQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAA
gRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE
9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0N
IDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hM
gACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBA
YBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF
9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0d
oZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhn
BAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQEC
BEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ
0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0
gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAz
AQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAA
gVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU
0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0
hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGc
ESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQI
EAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRC
QE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDT
ADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDM
BAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwEC
BEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFR
QE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDT
EcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRy
RoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEg
QCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAI
AT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBP
A8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAy
EyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQI
EBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRG
AT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBP
RyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHK
GQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaA
AIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAg
BPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9
DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPI
TIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMg
QGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAY
BfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9
HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0co
ZwQIEAgBPQ0gMwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkB
AgRCQE8DyEyAAIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACB
ENDTADITIEBgFNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0
NIDMBAgQGAX0dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0g
MwECBEYBPR2hnBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyA
AIFRQE9HKGcECBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBg
FNDTEcoZAQIEQkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0
dIRyRoAAgRDQ0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAgBPQ0gMwECBEYBPR2h
nBEgQCAE9DSAzAQIEBgF9HSEckaAAIEQ0NMAMhMgQGAU0NMRyhkBAgRCQE8DyEyAAIFRQE9HKGcE
CBAIAT0NIDMBAgRGAT0doZwRIEAgBPQ0gMwECBAYBfR0hHJGgACBENDTADITIEBgFNDTEcoZAQIE
QkBPA8hMgACBUUBPRyhnBAgQCAE9DSAzAQIERgE9HaGcESBAIAT0NIDMBAgQGAX0dIRyRoAAgRDQ
0wAyEyBAYBTQ0xHKGQECBEJATwPITIAAgVFAT0coZwQIEAiB6un9jx9+9fU3f/UIECBAIAS++frL
hw/ev/f67RtXzp8+efzYY9++Y8dPPn7+yo1br927//FnXx4F1SNAgACBEPj6qy8+e/D+3dduXf/H
nh5evvHSnbfe++jTL46C6hEgQIBACHz15eeffvjuW3deun758O8+n54+vHT9xVfefOd/H3z28OHn
HgECBAiEwMOHnz744O0/vPLitUuHBz/5ef/E6XMXr958+fd/eu+Djx587BEgQIBACjz48IN37/3u
5ZvPXjx3cOLH35+eODh74Znnbt/5w5/efu/9+x4BAgQIpMD77759741Xbz/3zIWzp37s6bETp848
ceXazV/d+f2bb9299yePAAECBELg3t233vzdq7+8ee3K+TOnThz7/vv9oy/4j37gf+bGzdsvv3Ln
tdc9AgQIEEiB1+688vLtmzeevnDu0ddR3/X0sWPHTxycOX/pmev/dfPFW7duewQIECCQArdeevH5
5649fen8mR9/ffrYY8eOPqAenD1/8cozz167fsMjQIAAgUHg+rVnn7ly4SinP/l4ehTU4ydOnj5z
7okLFy9fvuIRIECAwCBw+dLFC0+cO8rpD789ffRXpI4+oJ44eXD6zNlzh4fnPQIECBAYBA4Pz509
c/rUyR++3P/ur5weO35U1FMHB6c9AgQIEBgFDg4e1fTHL6O+D+qjop44cdIjQIAAgVHgKJqPavr9
d/t/y+m3P/Mf/eFxjwABAgRmgaNs/nNNv83qt4t/ECBAgMAs8MNnUv9CgAABAgQIECBAgAABAgQI
/EcK/D9EPtf0CmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKOTU0MAplbmRvYmoKMzEgMCBvYmoK
PDwgL0xlbmd0aCAzMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy
MjMgL0hlaWdodCAzNTAgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUg
L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHt1WlT
GmsQhmEHZgYYdlEEXIgKRg1GMSZuYNziFiWoATdQ8///xBk8lkFTp6q/dd5Td38wZXyqHnv6GhwY
YHgCZjwBy/D576ds+GL9v/6fS/o/DQQCQfPH38Lf5fWCveWCQdtxXMPHcWw72Fuwf7/e5WzHDUc8
z4uaPJ4XCYccf8FX+/mns92wF0uk0ulBgyedTiXj0UjI8ff7fT7/eLYbiaUyw7l8oTBq7hTyuexQ
Ou6Fevd72c8/nhuJp7OFicnpUrk8Y+qUy9NTxbGRTMJz7Vfr2aFYemR8evbDx6VqddnUqS4tVuZK
xXwmHnaCL2+fZfnHSwyPlT5Uv6xv1upbhk69XttY/bQwUxxJRUP++Z55WpYdiqZzk/PLG1/3vh0e
Hpk6hwf7O5ufF0qjmVi4b72AbzMzWl5c2zn8fvajeW7qNBunR7uby3PF4UTE+X29gB2OD0/Mfqof
nJ7/bLWvTJ1266JxtL1amRxJer9fPivghBPZ4vyX7ZNm6/r2rmPq3N20L77vrX+czqU89+WzxV8v
ksy+q6zunl5e3Xa696ZO9+661fi2uVTKp6Jv1huZrKztnf286dw/PJo6D93b9o+D2lKpkP5zvYX1
/Ubrtvvw+MvUeby/u2oe1qtl1jPwhFyPd++vZQtOcIJT5wnw7vHu6cgTtIITnAImOhFwglNHnqAV
nOAUMNGJgBOcOvIEreAEp4CJTgSc4NSRJ2gFJzgFTHQi4ASnjjxBKzjBKWCiEwEnOHXkCVrBCU4B
E50IOMGpI0/QCk5wCpjoRMAJTh15glZwglPARCcCTnDqyBO0ghOcAiY6EXCCU0eeoBWc4BQw0YmA
E5w68gSt4ASngIlOBJzg1JEnaAUnOAVMdCLgBKeOPEErOMEpYKITASc4deQJWsEJTgETnQg4wakj
T9AKTnAKmOhEwAlOHXmCVnCCU8BEJwJOcOrIE7SCE5wCJjoRcIJTR56gFZzgFDDRiYATnDryBK3g
BKeAiU4EnODUkSdoBSc4BUx0IuAEp448QSs4wSlgohMBJzh15AlawQlOAROdCDjBqSNP0ApOcAqY
6ETACU4deYJWcIJTwEQnAk5w6sgTtIITnAImOhFwglNHnqAVnOAUMNGJgBOcOvIEreAEp4CJTgSc
4NSRJ2gFJzgFTHQi4ASnjjxBKzjBKWCiEwEnOHXkCVrBCU4BE50IOMGpI0/QCk5wCpjoRMAJTh15
glZwglPARCcCTnDqyBO0ghOcAiY6EXCCU0eeoBWc4BQw0YmAE5w68gSt4ASngIlOBJzg1JEnaAUn
OAVMdCLgBKeOPEErOMEpYKITASc4deQJWsEJTgETnQg4wakjT9AKTnAKmOhEwAlOHXmCVnCCU8BE
JwJOcOrIE7SCE5wCJjoRcIJTR56gFZzgFDDRiYATnDryBK3gBKeAiU4EnODUkSdoBSc4BUx0IuAE
p448QSs4wSlgohMBJzh15AlawQlOAROdCDjBqSNP0ApOcAqY6ETACU4deYJWcIJTwEQnAk5w6sgT
tIITnAImOhFwglNHnqAVnOAUMNGJgPP/i3Nt7+znTef+4dHUeejetn8c1KrlQjrqBi1r4GmsgBNJ
Zt9V1nZPL6/vuvcPps5956bV+FZbKuXfrpfIFj982Tk5b9/cdbqmTuf26vJ0f2NxOp/y+q9nhxPD
E3MrW4eNi9bV9Y2pc92+bB7vrC1M5ZKe04fTDsczYzPVjb3js+b5xaWpc9FsnOzXV+aL2UTk1Xqh
6GB+qrJS2z04Oj75buqcHB/sba0ulseG4mE78PLRYgVdL5mdmFlYWa9tbW/vmDrbX+sbnxdn3+XS
0dCr9ZxwbDBXLM9/rH5a+WzurCwvVd5PFoYSETcYeP67MDBgBWw3ksjkxidLM7Ozc+bO7Pvy1ERh
KPl0vH//6vlfLStoh7xEejhXGBsfnzB2xsfHRnPZwWQ07PQdr3e+oBOKxBKpdCYzZPJkBlPJmBfq
bfdis3e+QNB2QxEvGvMnbur4v3vUi4TdN9s97ecv6LhuyPBxXce2X9+u9w5a/gEDQX9ss8ffIODD
7JP5/Anj/19vRdPnaY3nld7+8/Qz07+8XYrveQJ/5xP4B/LYVFwKZW5kc3RyZWFtCmVuZG9iagoz
MiAwIG9iagoxNTgzCmVuZG9iago0MSAwIG9iago8PCAvTGVuZ3RoIDQyIDAgUiAvTiAzIC9BbHRl
cm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVd9v21QU
PolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8AUDZAw9I
PCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWaGVWIlquu
nc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJPwG4VHX0Z
+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzYZi+3YV8D
GMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0HPBLsF+v
uUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgjONd1ZxKz
pBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyoBc3SOjcz
ohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrYBbueF9qQ
n93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiEhcPLYTEi
T9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrBDgUKcm06
FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfSPqdraz/s
DjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1cAdMlDetv
4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0nfS/9TIp0
Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8ek6fkvfDs
CfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWWing6noon
SInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8OokmrdtY2
yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/wjvrVmhb
qBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83Gv+uNxo7
XyL/FtFl8z9ZAHF4CmVuZHN0cmVhbQplbmRvYmoKNDIgMCBvYmoKMTA0NwplbmRvYmoKNyAwIG9i
agpbIC9JQ0NCYXNlZCA0MSAwIFIgXQplbmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0aCA0NCAwIFIg
L04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt
CngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UU
C4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68Fc
EhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2
PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXh
o4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+Tlo
ngB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c
7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA
8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aan
pktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+
nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm
9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApB
MdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oI
eUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmw
OxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQC
qUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgn
rD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U
74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxi
KbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYU
T0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3
l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA
6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNS
GaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZ
avvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTH
tGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3
Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2
cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9
i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w
3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqML
DBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Sn
k+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAno
CqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3
BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn3
0t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5Ln
xivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNC
JWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHM
Eeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuN
ZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699Z
fVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKo
sr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/r
ouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE5
8eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pn
S8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19
ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3p
fd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+p
zytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt
52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVh
bQplbmRvYmoKNDQgMCBvYmoKMjYxMgplbmRvYmoKOCAwIG9iagpbIC9JQ0NCYXNlZCA0MyAwIFIg
XQplbmRvYmoKMjYgMCBvYmoKPDwgL0xlbmd0aCA0NSAwIFIgL0Z1bmN0aW9uVHlwZSAwIC9CaXRz
UGVyU2FtcGxlIDggL1NpemUgWyAxMzY1IF0gL0RvbWFpbgpbIDAgMSBdIC9SYW5nZSBbIDAgMSAw
IDEgMCAxIF0gL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtcLbcppAAADQ//+gxjRp
TGObC4gKKAoKgqLCsiz3m2+dzMShBFCWhTPHs85e8+Ds/dcFZ7KZCzLXxOiYWdNG5nQUGVn+lKH2
U3SqekxRsX1MO3hIbZzwkN6upxBvAvVrLT35vO/nLrFKwS4hqiXgxhho35tafKMam5021NjY9lOJ
jcLIUL6elKh9OTrhP8rRtZvo2MPDOuy+FB7q61LYshjqbe/F8DLYi8WrYN/5ZbDroxDsrtaEoKqv
CfUXvkZWXfgV577aR95XeX97u7flG+e8bYMK5+FlPYWszHrfzzy5uivPCE5d+XIzdTs7cTcNricu
RsZdf3XWTPsS4xSOHamrtCNdirTTJuWIFZFI5VcUqv2BVgSXH2j5TvwNLUuFN9T0qy00vni1K/61
F4T/2HPCI3tekx/ZxZAflb5AHj/3AvO/IUf4GXKX7DPEPoRsdYsd5mdDq/aTNWt7+mR9/kX20ZqW
Th4tjA9g0jjzACr+BAzhezAmOQDj+vQAFJv0oPTOpPFTd2b+h0ld/Q8JxfzTCmVuZHN0cmVhbQpl
bmRvYmoKNDUgMCBvYmoKNDA0CmVuZG9iagoyNyAwIG9iago8PCAvTGVuZ3RoIDQ2IDAgUiAvRnVu
Y3Rpb25UeXBlIDAgL0JpdHNQZXJTYW1wbGUgOCAvU2l6ZSBbIDEzNjUgXSAvRG9tYWluClsgMCAx
IF0gL1JhbmdlIFsgMCAxIDAgMSAwIDEgXSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K
eAGVwgc7G2EAAOCfVpTalKJmrVIUNWuVClmSEBEy7b333n6Amdh7xyb2bnO9a3K57+4+7/Mqx16V
oIqxV/ToqwL9ohgFl4++kB55kePLRl6wz7IRqtKRZ+kwbMnwM/JJMmxw6EkCWjD0BHXwqWDwMf8t
xYOP+gOPYsAH8QA6b+CBav9DHlbU/0D5XtSvn9t/r9sHVdh3D3on7AXM6b2D3XOXjXub3UNa0HNr
vPtWQJLffYu84XeT77rhI3ldN/Czuq7RnddZdLmd16Q7rrnoK26HLgc6u+OK3U7xkt2uz2q/BGy7
ZIEy2y5JapltBlu1zFZt5ltmtGr1W7QZLRcUGS0XVJsvGNj05gvseXozzd/N57pNUNOazsAbz9II
UxvP4J6mNpz+esuUhlPc+tMU3JOUenRy/Qn9upNkZFLdCcnjpDrjiXXH6NrjRLoJtcf4Rwm12Jqj
BPyfNUeQ42uO4qv/P4yvphpXfQhYdRgHGlt1GFt1QL/yILbyIAa2JqZSE224QhNNOapCQ7VcE1W+
/++P8n34keX7umXAe5FluBFle+ClexGE4aV7hLvhpYQlu+Elu9/fMqxkF7sTVkw1tHiHZtFOKDak
aAe5HVJE/1vRtm4hzK3gQpLKrWDCIOUW3c0gJVKx+RV6oGLTuHwzUH8jUK4fIN+gL9sIQPrLNkDX
/WWAfrJ1tHTdj66vdN3gmq/UoGTN1+AXyRp8H8maT8HfqzC9C1YB81e9Qb3yV6CKV7zEK55Qlz3F
uh6G85Y9yLvnLVNechfpfxYtwXcTLenmEi+65Rp3zV0EFy66EroIF/EXXIQkcxY+QXfOWcDOO+cg
s+edSTplz9MXzDshPwrm4DsK5tD8OUeqs478WQeKvFkHfHveLGW1PQ9tx1PbZcG2zVIDctW2XBWx
DVcFlaOy4aisjc9Yc0hbcWb02TNW5C3ZMwanLdmErGlL7AfWNHwL1rQFa8qCCdWcOQWeOWWOO2me
OfkefsakGf0JswxdU2LGhClJE8YE+XETBjJ93AT5Ln0c+A9PJWfyCmVuZHN0cmVhbQplbmRvYmoK
NDYgMCBvYmoKNzgwCmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDQ3IDAgUiAvRnVuY3Rpb25U
eXBlIDAgL0JpdHNQZXJTYW1wbGUgOCAvU2l6ZSBbIDEzNjUgXSAvRG9tYWluClsgMCAxIF0gL1Jh
bmdlIFsgMCAxIDAgMSAwIDEgXSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVwodW
2lAAANAfa6uIiIiIiIh774GIiNQ6cbE3jv5VlSUo7sHSOtlaSUPDS95L0nvux8/9D+j9vQ/K9/09
+L3dd7Z33nchC7s7sJ7Crqeww7K7sOMueMjzHjelK+/Bul155s68G+ty5svmXE5YR86FdTpyDO05
Z6nDniubddgpbVlHqd2WZWjN2svarNnSjM0KtmRsYKslg2zOWMEWcwabtpgpTWkL2GxKwxvTZkqT
MY1NmYxgQ8pEaTSk4PUpI6xBnzLo34DbbwZE/fYb+dabHnF765V883UbcWvzFbjxuoW+ufECXH/Z
RN9YfwHqXjboPq/rStee15nq1p7xq886uk+61ae1f1ee1piurjwVLzN+XF1+XPl76XGFxeWlx+JF
+r+XF4uXPv/4j4sLv5k+LC7gf3x/YFv7sMD8fkGLnb//zr7mXsswqdVg55LaueQ8y+rkPFajTqIn
NGrsbEKDnZtNMFQl5krVqgR6XK2Kq2eIszNxhsr4bKlKGUeMqZQx1TRwZjpGVxGbKatUxBCjSkVU
OUU+PRWFn4xOUyomo7B3ignIqYk7+PG7KcrJ8TvK28kx+ImxW8jR2wnY8dFbypvxEeSxkRvg8M0Y
+ujwDXDoehR9ZOgaOHg9gj48eE0cuBqmPTRwRey/GqI92H9F7LscpD3Qd4nvvRxgsb/3srjn8wXj
vp6L4m5We7svers+n7PZ03Xe08l2d+d5d8fnMza72s/+Y9tZZ/Epq62nHSzLTzvkp+3yCKstkfaW
SBvLskibLNIqO2HefNKKlTefMJeeyPHHLVKmTcctpbKmY7qSYxk+LJOEm+k3hpvLShvDdMVhKT4k
FYeaaDaEmsCShhCyKCTBH0lExY00648aKcX1R5DCIzExKBbiG4RByLpgA6yoLggpCIqIAZEAXy8I
kNcG6hGFtQFyfkBI9Av5xDq+n7zGX4cuqPETeX4B0CfgAWt5PmK1r5Y2v9qH5/r45F4+F1jD9eKr
vDVMeVVePMfLAx7yOOTVnEN85WE1U27lYXEF9QG3ArKq4qDqG9ucbwecr9S/OF8hK7/8gv0Dn9dS
rgplbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjgwNQplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAv
UGFnZXMgL01lZGlhQm94IFswIDAgNzkyIDYxMl0gL0NvdW50IDEgL0tpZHMgWyAyIDAgUiBdID4+
CmVuZG9iago0OCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgL1ZlcnNpb24g
LzEuNCA+PgplbmRvYmoKMTAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBl
IC9CYXNlRm9udCAvWVhBVEVQK0NhbGlicmkgL0ZvbnREZXNjcmlwdG9yCjQ5IDAgUiAvVG9Vbmlj
b2RlIDUwIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA2OCAvV2lkdGhzIFsgNTE3IDM0OSA1
MjcKNTI1IDIyOSA0OTggNzk5IDIyNiA1NDQgNDc5IDQ1NSA1MjUgNzE1IDUyNSA0OTggNjE1IDQ4
NyA4NTUgNTI1IDQ5OCA1MzMgMzkxCjMwNiA0MjMgMjI5IDQ1MiAzMzUgNTI1IDU3OSAyNTIgNTU3
IDQ1MyA0NTkgODA4IDQzMyA0MjAgXSA+PgplbmRvYmoKNTAgMCBvYmoKPDwgL0xlbmd0aCA1MSAw
IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZPNjpwwEITvPIWPm8MKYzOwIyGk
aKOV5pAfZZIHMHYzQcoA8jCHeftU9U42yh4K6aO77C5syufDp8M8bab8lpd4lM2M05yyXJZrjmIG
OU1zUTmTprjdSd/Fc1iLEubj7bLJ+TCPi+m6wpjyOyyXLd/Mw8e0DPKB777mJHmaT+bh5/NR3xyv
6/pbzjJvxhZ9b5KMWO5zWL+Es5hSrY+HhPq03R7h+tfx47aKwURwVK8jxSXJZQ1RcphPUnTW9t3L
S1/InN6V7oZhjL9CLjr31KPZ7g0eCQ9n8QhWnfeedw7f0uHYHJJxtvqv2bvXgYbxPomr+o6ydofG
zjkgZG3riB4IWduMxBoIAbW6A0LAyGoDhIA7IgahgIm4B0LW1uoNQAjVitUBCAEHYgRCwJqYgBCm
aokChFAV4gikbOWBHt+Wwkb0eoSjEFAR4bwGrDmVRzgKKzO+RzgKHzAQEY7CUroywnkN2CribLye
T6OIcF4DNnt6EY7Cyg0R4bwmanUMpPGaqGZ8jzQUNqK3xvgUvIoYH23AHTfC91ONg1XE+BiPzU+s
YnwKS+FQcMH+HjXvGv+Jtzscrznj+uqPozebN3aa5e3fWpeVC6j+AC2t70YKZW5kc3RyZWFtCmVu
ZG9iago1MSAwIG9iago0NjYKZW5kb2JqCjQ5IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRv
ciAvRm9udE5hbWUgL1lYQVRFUCtDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBbLTUwMyAtMzA3
IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBI
ZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9NYXhXaWR0aCAx
MzI4IC9Gb250RmlsZTIgNTIgMCBSID4+CmVuZG9iago1MiAwIG9iago8PCAvTGVuZ3RoIDUzIDAg
UiAvTGVuZ3RoMSAyMzY2NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVe3l8VNX9
9rn3zr7vM8kkmUkmmUmYLGQhC4RkQhYSQiCBDCRAICFhlX3fQcANxaVuxd3WraIyGUCC2IqW1m6o
tS5tXardtCpWW20VSPI+5545IVr9ve/n8/7TX5Jnnucs98w53/M9555z7s2GdRsXET3ZQyQytndl
zxoi/5RUgrp7N23ws3DWUkKUKYvXLFnJwmP2E6JNXrJi62IWLvmIkFDf0kU9fSxMLoJLlyKChYUS
cObSlRu2sHDxfeC7VqzuTaSX3IVw68qeLYnvJ28i7F/Vs3IRGD/zWvHhX7NuUSJd6EBxFsTtueJ3
Q9V7LrZE37hmQ2TNhtN7KGIbT+8hxESIgBwhwU8s5MdETURwAUGJ1huFvUSBVJquvGfg4L9/aV1g
rvycJGkQQcipD3f8ivLzVz1y7YXzg9dqP1I/iaAWJbAfXKe+Z/D3hOjuu3D+/H3aj+SSEokyheJa
yT8g7j+m9QhTIPZxsZeLy7nYw8VuLnZxsZOLHVxs52IbF1u52MLFZi42cbGRiw1crOdiLRdruFjN
xSouVnKxgovLuFjOxTIulnKxhIvFXCzioo+LXi4WctHDRTcXC7iYz0UXF/O4mMvFHC46uejgYjYX
s7iIctHOxUwuZnDRxkUrF9O5mMZFCxdTuWjmYgoXTVw0cjGZiwYu6rmo46KWi0lc1HAR4aKaiyou
JnJRycUELsZzUcFFORdlXJRyMY6LEi6KuSjiopCLsVwUcJHPRR4XuVyEuRjDRQ4X2VyEuAhykcVF
JhcBLjK4SOfCz4WPizQuUrlI4cLLRTIXSVx4uHBz4eLCyYWDCzsXNi6sXFi4MHNh4sLIhYELPRc6
LrRcaLhQc6HiQsmFgguJC5ELgQuSEMIwF0NcDHJxkYsLXJzn4ksuvuDi31z8i4vPufiMi39y8Q8u
PuXiEy7+zsXHXJzj4iMuPuTiAy7+xsX7XLzHxV+5+AsXf+biT1z8kYt3uXiHiz9w8TYXb3HxJhdv
cPF7Ln7HxW+5eJ2L17h4lYtXuPgNFy9z8WsuXuLiRS5e4OIsF7/i4pdc/IKLn3PxMy6e5+KnXPyE
izNc/JiL57h4lovTXDzDxY+4+CEXT3NxiounuDjJxQAXJ7h4kovjXBzj4igXcS76uYhxcYSLJ7h4
nIvHuDjMxaNc/ICLR7h4mIuHuHiQiwe4+D4X3+Pifi7u4+JeLu7h4m4u7uLiTi7u4OIQF9/l4nYu
buPiVi5u4eJmLr7DxU1c3MjFDVxcz8VBLq7j4louDnBxDRdXc3EVF1dycQUX+7nYx8VeLi7nYg8X
u7nYxcVOLnZwsZ2LbVxs5WILF5u52MTFRi42cLGei3VcrOViDReruVjFxUouVnBxGRfLuVjGxVIu
lnCxmItFXPRx0cvFQi56uOjmYgEX87no4mIeF3O5mMNFJxcdXMzmYhYXUS7auZjJxQwuWrmYzsU0
LqZy0czFFC6auGjkYjIXDVzUc1HHRe1RulrGqjmeVuXDmjme5gTtZaHL42njEdrDQrsZ7YqnGRC5
k4V2MNrOaBujrfHUGmTZEk+tBW1mtInRRpa2gYXWM1rHItfGUyfhgjWMVjNaxbKsZLSC0WXxlHrk
XM5oGaOljJYwWhxPqUOWRSzUx6iX0UJGPYy6GS1gNJ9d18VC8xjNZTSHUSejDkazGc1iFGXUzmgm
oxmM2hi1MprOaBqjFkZTGTUzmhL3NqENTYwa494pCE1m1BD3NiNUH/dOBdUxqmU0iaXVsOsijKrZ
dVWMJjKqZDknMBrPLq9gVM6ojFEpo3GssBJGxayUIkaFjMaywgoY5bPr8hjlMgozGsMoh1E2oxAr
Osgoi5WZySjAKIMVnc7Iz67zMUpjlMoohZGXUXI8eRqMlcTIE0+ejpCbkYtFOhk5WKSdkY2RlaVZ
GJlZpImRkZGBpekZ6RhpWZqGkZqRKp7Uim9XxpPaQApGEosUWUhgRGQShhkNyVmEQRa6yOgCo/Ms
7UsW+oLRvxn9i9HncU+7b0D4LO6ZCfonC/2D0aeMPmFpf2ehjxmdY/QRS/uQ0Qcs8m+M3mf0HqO/
six/YaE/s9CfWOiPjN5l9A5L+wOjt1nkW4zeZPQGo9+zLL9jod8yej3uno2mvBZ3zwK9yugVFvkb
Ri8z+jWjl1iWFxm9wCLPMvoVo18y+gXL8nNGP2ORzzP6KaOfMDrD6Mcs53Ms9Cyj04yeYWk/YvRD
Fvk0o1OMnmJ0ktEAy3mChZ5kdJzRMUZH465qNDoed80F9TOKMTrC6AlGjzN6jNFhRo/GXZj1hR+w
Uh5h9DBLe4jRg4weYPR9Rt9jdD+j+xjdywq7h5VyN6O7WNqdjO5gdIjRd9kFt7PQbYxuZXQLS7uZ
lfIdRjextBsZ3cDoekYHGV3Hcl7LQgcYXcPoakZXMboy7uxB26+IOxeC9jPaF3cuRmgvo8vjzihC
e+JO3GyE3XFnKWgXo53s8h3suu2MtsWdfciylV2+hdFmRpsYbWS0gdF6VvQ6dvlaRmvizl6UspoV
torlXMloBaPLGC1ntIxdt5TRElazxezyRYz6WM5eRgsZ9TDqZrSA0XzW6C5Ws3mM5rJGz2FFd7Iv
6mA0m1V3FvuiKCulndFMRjMYtcUdETSsNe6gZp0ed9ABOy3u2AdqiTvyQFNZlmZGU+IOLCSEJhZq
ZDSZRTbEHbuQVh93XAWqizt2g2rjjj2gSXFbA6iGUYRRNaOquA3rAmEiC1XGrZ0ITWA0Pm6l46iC
UXncOhmhsri1A1Qat84BjWNpJYyK49ZcRBaxnIVxK23Y2LiVTkgFjPLZ5XnsG3IZhVlhYxjlsMKy
GYUYBRllxa3USpmMAqzMDFZmOivMz0rxMUpj16UySmHkZZTMKClu6UKZnrhlPsgdtywAuRg5GTkY
2RnZ2AVWdoGFRZoZmRgZGRlYTj3LqWORWkYaRmpGKpZTyXIqWKTESGQkMCKRYfNCH8WQudc3aO7z
XYS+AJwHvkTcF4j7N/Av4HPgM8T/E/gH0j5F+BPg78DHwDnEfwR8iLQPEP4b8D7wHvBX0xLfX0xL
fX8G/gT8EXgXce+A/wC8DbyF8JvgN4DfA78Dfmu8zPe6sdD3GvhV4wrfK8ag7zfAy9C/NoZ9LwEv
Ai8g/SzifmVc6fsl9C+gfw79M+Ny3/PGZb6fGpf6fmJc4juDa3+M8p4DngUiw6fx+QzwI+CHhrW+
pw3rfKcM631PGTb4TgIDwAnEPwkcR9oxpB1FXBzoB2LAEf1W3xP6bb7H9Tt8j+l3+g7rd/keBX4A
PAI8DDwEPKjP8z0A/j7wPVxzP/g+/WW+e6Hvgb4buAv6TpR1B8o6hLK+i7jbgduAW4FbgJuB7+C6
m1Dejbppvht0033X65b4Duoe9F2ne9h3hZTl2y+V+/YJ5b690T3Ryw/vie6O7ozuOrwzqt8p6Hd6
dzbv3L7z8M43dkZsKt2O6Lbo9sPbolujm6NbDm+OPiVeSRaLV0Qqo5sOb4wqNjo2btgofbZROLxR
qNsojN0oiGSjZaN/o2TYEF0XXX94XZSsa123Z11snWJCbN0760SyTtANDJ8+us6b1gCO7FhntDSs
ja6Orjm8Orpq8croclRwWfmS6NLDS6KLy/uiiw73RXvLF0Z7yrujC8q7ovMPd0Xnlc+Jzj08J9pZ
3hGdjfyzytuj0cPt0ZnlbdEZh9ui08unRachvqW8OTr1cHN0SnljtOlwY3RyeUO0Ho0nKZYUf4pk
oRWYloKaEK8waaw34n3H+4lXQbwx72mvZDMn+5LFHHOSUDs9SVidtDvphiTJ7HnRI0Y8ObkNZveL
7j+4/+5W2CPunPwG4rK4/C7JSdvmammnbTvqqq5jXDhObmuLKxBsMDsFs9PnFOt9ToFY37F+YpWc
z1hetIhms2A2D5vFiBnZzSafSaQfwyYpYiosazAbfUaRfgwbJVfEiBha+ZChtb3BrPfpxWi1frpe
jOiraxsi+ryxDUQS/AKe/FhAkobWRnD6GgYEctQlKIUB4cb+9pnhcPOAhsxojmla58aEq2NZM+ln
pG1OTHV1jETnzO3oF4TrO/sFsbY95mhum8PCVxw8SCalNsdSZ3bE7kvtbI7tgYhQMQxBUvtdZFJn
eP76jevD4Q3z8TF//Yaw/IeQsJGG8IME/K3fgDD9BSFMaMq3/7BsyLdgPX7kYljp337J/4IU4X9B
Hf/Lq9hP4KIdNcPiftIn7gP2ApcDe4DdwC5gJ7AD2A5sA7YCW4DNwCZgI7ABWA+sBdYAq4FVwEpg
BXAZsBxYBiwFlgCLgUVAH9ALLAR6gG5gATAf6ALmAXOBOUAn0AHMBmYBUaAdmAnMANqAVmA6MA1o
AaYCzcAUoAloBCYDDUA9UAfUApOAGiACVANVwESgEpgAjAcqgHKgDCgFxgElQDFQBBQCY4ECIB/I
A3KBMDAGyAGygRAQBLKATCAAZADpgB/wAWlAKpACeIFkIAnwAG7ABTgBB2AHbIAVsABmwAQYAQOg
B3SAFtAAakAFKAFFzTA+JUAEBICQPgFxwhAwCFwELgDngS+BL4B/A/8CPgc+A/4J/AP4FPgE+Dvw
MXAO+Aj4EPgA+BvwPvAe8FfgL8CfgT8BfwTeBd4B/gC8DbwFvAm8Afwe+B3wW+B14DXgVeAV4DfA
y8CvgZeAF4EXgLPAr4BfAr8Afg78DHge+CnwE+AM8GPgOeBZ4DTwDPAj4IfA08Ap4CngJDAAnACe
BI4Dx4CjQBzoB2LAEeAJ4HHgMeAw8CjwA+AR4GHgIeBB4AHg+8D3gPuB+4B7gXuAu4G7gDuBO4BD
wHeB24HbgFuBW4Cbge8ANwE3AjcA1wMHgeuAa4EDwDXA1cBVwJXAFaSvZo+wH2ofsBe4HNgD7AZ2
ATuBHcB2YBuwFdgCbAY2ARuBDcB6YB2wFlgDrAZWASuBFcBlwHJgGbAUWAIsBhYBfUAvsBDoAbqB
BcB8oAuYB8wF5gCdQAcwG5gFRIF2YCYwA2gFpgPTgKlAMzAFaAIagclAA1AP1AG1pO+/fJr+b69e
5397Bf/L6+dZMJ++MUTI0M2jXxIirWQ5WU/24PdKcpDcTJ4hb5CFZB/UIXIfeYj8gMTIs+Tn5PWv
XPX/GRjaqlxJDNIJoiJ2QobPD58beggYUJpGxdyMkF3hvxQzbBn++GtxHw/dPGwZGlDZiE6+1ii+
jNL+KQwOn8f9VUWMw6U0LF4FbZa/6VP1PUNHhh7+SgNaSRuZQ+aSeaSLdJMetL+PLCXLYJnLyAqy
kqySQ6uQtgR6MUILkAtziawv5VpN1pDVZB3ZQDaSTfhdA70+EaJpa+XwRrIZv1vIVrKNbCc7yM7E
52Y5ZgdStsmxW5Cyi+xGz1xO9sqKM4vZR/aTK9BrV5GryTXosW8PXTOS6wC5llyHfr6e3EC+TR/8
SsqN5EZyE/kO/OEWciu5jXwXfnEnuetrsbfL8XeQe8i98Bl6xa2IuVdWt5HbydPkp+Q4eYIcIU/K
tuyFbZlFuF0Wy5ZeAxvsQJv3jaoxs+bmEWvtgjVouw8k2r0F9ts76opNCTtS6+1DTmqdA4l+oKXs
TMRwS9yIljF9qZ3URrQNN3ylnfyK/1ssbTG1012wF7cMtdltiLvjP2JH5xitbyN3YwTej09qVaq+
B83UvbIeHX/PSN775LTvkwfIg+iLhwlVnFnMQ4h7mDyCsf0oOUwew+8lPVqx1CfI43LPxUg/iZOj
5Bh68klyggzI8f9T2hHMHV+/5miirPhIKSfJU+QUPORH5DRmmufwy2N+iLhnErFn5Fws/BzepTwj
56Kpz8G3nscM9QvyS/Ir8iL5CUIvyJ8/Q+gl8jL5DXldMEL9mvwNn4PkJeWf8WpmDV68fAq9cReZ
T+ZHJvctmN81b+6czo5o+8wZba3Tp7VMbZ7S1Di5ob6udlJNpLpqYuWE8RXlZaXjCvLzcrODWZmB
DJ/HYbWYjXqdVqNWKRUSVra59YGGbn8s2B1TBAONjXk0HOhBRM+oiO6YH1ENX80T89PrepD0lZwR
5Fz8tZwRljMyklOw+CtJZV6uvz7gj52tC/gHhDltHdAH6wKd/tg5WbfIWhGUA0YE0tNxhb/es7TO
HxO6/fWxhk1LD9R31+XlCv16XW2gdpEuL5f06/SQeqhYdmBNv5BdJchCzK4f3y8SjZF+bUzKqu/p
i7W2ddTXedPTO+U4UiuXFVPVxtRyWf5lMdSZXOvvzz194LoBC1nYHTb0Bfp65nXEpB5cdECqP3Dg
qpg1HMsJ1MVytv3ZAwMuiuUG6upj4QAq1jxj5AuEmDLLEvAf+Jyg8oFzH6HWo2J6EjGqLMvnhCbS
Jo6YKSb0cE1QN9QQ7UtPp3W5diBCFiIQ29PWwcJ+stAbJ5GCcGdM7KYpp3mKM0pT9vCUkcu7A7Bs
faC+O/G3aakntmehPy8XPSv/ZcUUWUj3x6Rg98LepZR7Fh0I1KGFsCVpx6FNHUSkJ2HM+v6xBcjf
041GLKNmaOuIFQTWxByBSczaiEAhWfXLZnbIl7DY+pijNoaXqBNXxQrqcS1cpP4A7RhaQVpWoK3j
JCkefqe/xO89WkxKSCetR8xVi04J1h/o6Fsc83V7++Cfi/0d3vRYpBPm6wx0LOqkvRSwxHLewdfh
Bx0oX4W2fS03z4xmx9RZGn+H6JU6aW8hwt+Aj8CkSiRYYioWpD06qdLfIXgJz4ZvSeSg6ivlICBl
1TbiYjAurW30psO55Z//oUpe1gBUI6YZqZMClVBeqhP7nm+tGstNK5Tjr19UN6qCXykUAbmCidK+
uZ4itUXCGKiChnZnI21DXq4I7UeyJiainXIU7UWPP0Za/R2BRYHOAHwo0tpBO4faWu7f5pkBejAo
93bCS9q/EmLp5SwtRtKb2zt4gJ7ZxBrCcr/SbpXDk+XwSLDxa8lNPNl/QBNonnmAfnkgUSDxYwSh
c1TBpp5ry20lGKwNmCgDDT0Bv8XfcKBnYHjPwgP9kciBNfXdS8djGBwINPUdCMzsqERfyuN+p3cb
/WobaRaa2yfl5WLumdQfEK5u648IV8+c03ESL+P7r27viIs4FO2e1NmfibSOk35CInKsSGNpJM3i
pwFa0gwENHJ+78kIXuaXUxVyhBzuxbmsHMcyIU4gvQMii7PwfCLiFCwuIsd14gcjzLMUXYB5uN7f
R7tnR+fSA92ddHARF7oSf0JMCFSRmBiowlGuyhDTBRZNiukDk2h8NY2vZvEqGq8OTIoJLgHGGcCc
dKA7gHkKLteBI/JOeIeFer+Y5R8YHm7vSD/rPdeZjiExD5jTEdOGcR9QZk1BvskU3YieHNvT20Pr
QaIY6nRkNvV2YizwApGlKaZFCdpECcjRIF9D3REX9aJv0IHy9XsQiO3pjHWG6Zd2LKM18vstMdIY
GI9uZ2Uqg/SLCjoP2AJF1LGRNabLuoqSFnUjOKSWY7wI4ssw4dIWqQ2oeW8ASb3dfvSAgvTOhKuz
uVRH+w0xizAlKoKLZOi8iURCmyVl6Y26mDYfBeKPan0+CsSfuhNGoY2XQ1clMuC7LTE9ahQcZcrE
BbAOkppoXfB3FSpPsz5Li2kbIDMCWzA10krLX6VGcsyY1dSDyZ9dr0dMoJxfjLI0WTSKlnGGxapp
yw2wu5TVPjD8cGArnQH4T15ugN4cqGMS70k4Nuk88PWI2NxwXq7m67FGOfrAAY3xmy9g9tIYR5iW
4q/HvYYQBf03lhfB95OAYg55TFFHehQfkcdEBXlM6iKPqV5HXAb042Sy9Fdill4l8xQl5JC0kMwB
d0sXSJdqE8nCWdoV0vfJIfAhVR85RPMoyuU8h8RfIH86aROfIOmKjQmUkFuku0mGcoCMkzaTHOle
koFrCU6B66WLw/+SLmJljKrhl/4YsMebAU4nmfg/mSTiJkbiwP/bOJEuIdWOHaCfuEgWUeK/jTTE
Q4Lwm2TkNhEb8REvSSMiykghGURHrChHLZd7P7lfKBD+Ii4UX5SSpaUKp+J6ZbfyedUmtVl9p6ZI
8xvtY7os3TN6Uf8nwwajaDxkspl+a243d5tfsyy2plo/t11h+8BushfaZ9nj+G4ytF56GbtVCeVX
kBYyjcx9mhhxrOQi44Xjx511dZo89Y9wZCQSPw6dNEQQaiNmhWg8kZxcHTgxTnVQsjYNCHnHqtUH
cZxaPfj24AsFg2+fs1UUnBMK3nr37Xctn75grSgofveVdwvHCtZ0qwyHSVSrHapARr44LhQsLS4u
qhLHlQQDGSZRjispLauSiovSRAk5WUyVSMOC9PLFOdL0QZW4K1A9q1iZlmx2GFVKMcVjy6vMssyc
m1WZn6qW1CpJqVFnl03KaF5Rn/F7tTXV6Uq1aTS2VJcz1aoefENpOv8PpelCrWLFhVsk1YR51ZnS
d3UaUaFSDaR5ksZMSG+aZbZbFHq7xerSqG1WQ3bdvMErnSm0jBSnk5U12AKzBIbPK3YpHeinILn7
JMkcfv+YwSJMDQwkRHBg+JNjesToucBzzU8iyTQqy0I/jfKnQf6MZAtZNDlXL7RkBoJZnxn0Bk9G
akBnFFwKAzFYDOKRwDOBFwNSwBAw2FJn2KLKKKmurrZVVBQUdHVZ3RVWSGux5VyRtRgWD3exsyA8
MctyuVSyyUNSumSSAhnBYGmZwOzsVgck+LpGsGT5fFl2rWL14F+XSzp7ICU1yyxohLjCmBRK849J
Nim2C38Qnpvo8poUktqgFSYM/Vxr1CqUJq9LEdebNJKkMesPDm4n8KnHME4FeFcaCZNy8rNIss9j
EVp8FjP9MOLDY8CHH23FW3b5kexkZwTpzgjSnU59Ls2cSzPn0sy5NHMuzZz7lFiE85PTx6FJsBiW
Poqc4E+OIrPMyA/+11FcIqcjZ/GAaIkY79OfxuBIDn1WWKjOHBDw9kNbyYCg71e3k+pz1bLfVggF
Xe/KVit6JcwE3DkcrmAaRnWYFIH0jOA4a0lpcTq80kn9OU0SSvLFQMBKndl+SSoEX/n03rVNQ0+4
c3LcQnDDLb1FrnDNmHHz6rOHBpPL50yJn6mdUZo0LWvyZW0vnJ/QURsU1k9cMqNqjNMXUuwN+XLb
t7Xkt08ut+nGzVglCgVTx6UMdQUmTB98a3xHpW+oPKVsBmaVnuFPFAZlGkbxwqMpZEI4YRWwbBXw
R0dhFfDH1CpyOqwS/pFYjDnHIxRgjgkKuXH7TMUpYQwZR8YK+f3aWRjSr5yjEApY8y2vnSkcm+Uw
scFbIg9LFTUAHaZ0ADsdaRiqbLgqDKJS44gs2N6065c3tMy87de7y5fPafBqlJJCo9eYiqavnT7r
YF/ZuN4b57asbysxq3Uq6YTFYzM5ckLe9gc+vfv+i0fmOf1jvCZ7ss2RYteGCkL1Vz67Y/sPd9cE
C4IqK50lqZfdAC+j8+bmSGp1umCnnmOnnmN3oM12Gxps96C19lPUc0gy85jkhG1kRj6w7DHg948i
d/IpPF/SwjaGuKnNOyAE+5XMS7gtXuEe0QWXEL/iEupRDnDDrAc/eWjoY7n7sx55/+624yWrH73y
SP+OR9dViHc8cuHBGayjZ3///UPLju+fctFatedZei95bPi80IG5xUlaT1S7p7uPuCWS6Few3K8y
o+5gue5yOupOnkLddcOnTziFFp1lhjxJCAUJdy4c24UeZBOrlXWh6BQ6NI70JE+GQ6N1pruT0h2a
ZI1BrVSqDRrF77mSa4Wh3YxaJZPGk8TJTIn3GeTqyIzqgOXqgGVTOgdE6zGiNc9wDgjhfpVsRqHg
LLefXBs2opjjOK10XEnNCswtg2fcORpHhodWSXiJTjbNDq9dC5s9wat14X6tNSVhMVUYvlBJHotY
uqvWVInGsWPdBQW6fI9H7lY4htzd8A2Zv6nbUddIWmahwaCjfqSjfqSjM5BOBz/SUT/SUetiBook
UVNnlrbpPW5jgacwX+XLbvNF+aRcbcN0XFwtFPB5BHOyhbUZyloxsaC4mM7So3ojINCZOV8MCQHr
pS6id8g00S0U0+maSqcqrHH4ktzpdo04VCzpnakOZ5pDLw5NFjQOf5LHb1fnepf6x2Z6tMJmpXCl
PtkXTFpp9toNlzp1yYVb1Dq1pMCgw23wELel4qExmYbkbO/F2dJDaWOS9Fp7qpOOsuHz0vOwbArJ
IVv6M1UJPwTLHS8zbASWO15Oh3FU1Jhuayq1ZCq1ZKrFYBSmptJ5PHVALIoTa9aAoDuqUhkCmIeP
OtsM9H6WWECwAcZNJs+8dIYdbRj4iWLUYJOej2x+fMvNWnt6EvWXMcmCc0zLspVTc45PmN2Ve++d
05Y0ZEo399y1qnIof6TFj2ZnqN3V87bOnr68xDT4ZfbkXupLk4fPSb3KdNJE3jtJanA7N+NmXUPb
i3bKjDbJDLcAy45eMyDmRsJFEbtDmFoUseIuXpRZZPB66LVe6kReC67yWnCJl3qS9yk8Q4cnHfXK
Y/j00aQEOxg/abYKU4kh/5QQImVEJwQjequ/TCiL6A3CVCt9t0dHVZm1zOqqHBAMx2u8ypyZrgEh
p1+JyfscXRics9LFQTjcZTlnwTz+Cr23MS+UVw08kDBvRr5iXGJOYMuyfFUi/PVpXiX11m6+v6tm
9ewJbr1CY9CYilvXTinvqs0smrFs1dIZxROW3dQent1SaVcpREmlV+sL6rrGl7aWJBfNXL5q+cxi
4bK51+Nm6M/wZPmwPlNnZAfSylqLy6ZNKCyual87vW33rDxzks+ut3rsNsz+KYHU1LGTskqnVRYV
T5y5Fn1khle+Dq/MIItOeCIwr8eKGfD0MSgiuyCMLbsmPE9mJIC/6qJ0MFuxnECaVWUbELKPpia8
sAhT5qfyUuAnYcuZcMJC6ZccMJ2uYKm15OnqdUxXmqFb+DwKZdQolfiQ9mswbSnO2FOsmgv3jPjd
Qo01xW5ni0lsJcg8eFy19AtSjM1ULOI3T/JNKpgk6bXuEgP8pYS6Twl1mhILdSesW/4dMZFQyEwE
A6Fji4yn3oms4Pepl8qMCyjL7jt+QNREHFb3T0iJpUSccLpEICVCSUl+zZgBwRsxv5QhZGQoUj/I
nzLxTUOLghQk1kRd57CqLOhaO7+LrwPOhOd3VRSwkVlUUTh2PuYwuroMBseNY6tM2SzF4+h9cGRZ
X6WQJy81Wye4iotKy6RqS4o32WeacFPb5PVteVUbHlm2w1U4rWJiT1OhQWPQKtTeSbMWl/Rc3R58
4GBd3yRfZ2vN6okegwEzhmFOdUNWw+KaqWumZDWUtI7zpgZSNZYkc1JqciDVnhvd1X7GnVed0zBz
Uh2sewjWfVW5lowhE8kVx6urBV16acIVwPKoBsujmIZle5UOCF9EvM4wXUGE/bBomNo/TGezMLV4
eEDURbTEqSsdl65Qjh0QlE8Gp3gbLFMrIPuVLXQE0tnMjUVlYrVwyWZs1UAne75+woqS3//Yulye
2WA+tdUFa1WJ0qvFvTd2hZsaGkIam9fpSLGp1Ha/J8lv02Q3NzZmL7x2dvYTzpJZEX9VpD5Ut6O2
qqMsSXhv46n9Ddbg+JxVcD2FAnd0ZTmGq4KO2cG/5JQHLNP2xTbW7+2baBszqWjo0MzZlb3bMbrm
wGJ+6edYDF7Tn0LHFV1ng9+hvkVXGsdgDBKiRkMCWL4VgOUlphyPDOAP6AWhAVEfMRaYBFPSe76I
ztjowwJcPGafIn1YSMes1thYmDsgqPq1MNvgK2G67AzD3xKL8TMYh0XftPSUV6KBDMxOaSMLT8kv
KtVJlc0dBT23LRpXs/ZQZ7itbpxHqxJtRnOoMjp+8+70SFdlxazqsIHeBL9nTbIak7JSbZHtRzde
8cy2CZbkDI/J7rGFfOnZ6SeemL2vI5wZDmjsqXScdsMud+GpcRCr7WsjvuoJgt5bQUdnBV0hVNAZ
voJ6RwV1lopTeIeIkAJmtYKEscCysWTGRXI8chdQh9LZ0xv0FSGvwoRhqYx7pmCoK46aWpRT6a1R
dicsKtgUnvAqOgYvLSNGD8Eil3vEq6RgcPQSvUy6S21NcdBt7eRDc3uvm51dtPCmBdP3RdQOH/Up
7UO1O+uq4UHwqJr0iZGGUBJ3oM0ts1r29S/ccGr/5PpaUa820pWiUT1YD99ZuCNSt3cRfKkWtzaR
dMFahzCrhXGa/0RkTEFpdenqUslOR5PdDyvZ7em59H6YS63Ftnry/AZf+PJ4XfiBsEg3McfpaCtR
JJwPLPuYHMZlYDbBKaj90tNzn9+juFEhnlYILykEhSKl4M3gFM8H3aY1JtGk/SBFdrAutt/rWruO
T2pFb4WZs8n7PRhUwBlF+ii3wjgdve8RnaFS2aBq6VAoaTCe1rCmLdLXVGBQ61WSKKn1pbPWRlY/
vG585dr7epff2p33kLR188R5VRmiKIbSm7fMyncmO9WmJJvRbjbokzz2qm0D2zacvLy+bv2dHfa9
t+RPXVRGLZg1fF75qXIrTo12kLXHWlvztuCZ2pfHcrtyV5ABcfWTulz8VuD/BL6M75iXB4r4aidW
bGk0K5W1G871Tp7X2HGuqSHPX3GutrF4anBqEvUjeFJREZ2e6FrrLPzpbPG7RW+9Ky8JLO++QFeq
RUgZWRWw+xxdlY8sv0bfCC/dE3ET4HO/PJkpnOykhw5RZ/qltcTIuHWmF7mcyk+17lBaasit07lD
qWkht9amsfvpClc9dBmUB2tazdAKrnZbLHT22p3ZeNnk3Ek+g0bSGTVOf07SlErhlqyGZXWuvIBX
h5MhnVFtSwp66yeI6uRkxa9SgvQLgikpWUlabVLWhULsQzEP6jWS8+KH36z9mfZkqzradcWsHLPR
YPfa/alavXbxmtk9NEqh0er0Fo/Vn6LWqBev6fV6aI9dgZ1bm7IAO7d0ct2J6sD0wOqA5KJjH14P
lhcgctguh9+hEyjC8pwgx8OpXafEtVhvO9m96T+3VIl7FLZUXzyp89FTE7hA1bEkS5M8Ubx2LpyY
JBJzBNYvl6aIkTnBTnsHPVZaXOQSqjQ2tnvgdxV77oTxYYqkEePspztCGF8tjB0/JqcCoKvlQ1iJ
7cDdtYTcGjFUlwo5hUJhxCa0YGp/Sb6VQsj3DfAHdI0ih9HKwlN4OzSDGBKtMVAjwEhg2Uhg+ZZs
oHfiZFdeHqENJRGUQFwZemV2U0qDdarcYPkUTCjAjQIrE3nZVvSOvHhDu0caHhIueerIzTZxCgZH
VQuCyyXt0Ngzkr0Bj1k1tP/rFhHaNbYk7EYznFqjeegpYZVRjz2VBqdhRq3wjyEjt9OlW+zFl4VN
OqNWwoSgNXgsQ08NZVmdCZsJVbCZk0Tk/f1qeX8vNx93V7n59C5LzyLAbEVCYIdjOkuD3OJE/35j
v/5nX4504aWqJWqhfAnzcyv5IOK1WfBl8llJ0EI3FiEP/VwzQ2iwJ2oElmsE/oR6rcx0Gk/c5u20
o9LSXOjDtLQitmeWd890esdmGitXHaaoE610d9RahdWB3NBRqwW5WIT5akI2SOgUXsMtIhZBFW+e
goWDKmKsmVLVkFfelIf57FL/0/sjvzdWJPbdOIBObHjoXVL+54FR5x90gapSj/KK/4hIrMmcpRgj
2IazpZlT+RJcA7dJu8aRW5dfsb6ezk10vnLl1uZXbKjjjqOypbhdqRb11Buayjvrxlry2ponZ87e
1OQb6Q8xUDG/LrMjOngtd57/jMEWQg8X0uo1m6PTkwtqsgvrxtgnLr5mamLs3YceLCK3RMysB2k3
VpcIY76hl2RzIl42OzjRm3Shm6anaxc97S49XcDo6XpGTztOj149wUZdmoVaX5c3ZUxSZhM3va2C
mp2bObFjT1j7f7L1V03rlO5jNrVpPPlNY6t2/KcRb2+Zs31q+iXTmVu+ZrqvGAoG6qbzMV3Jvg0L
2UmIPBJJqc4Rsm1CjlUIGoWgQQhqhKBaGCMJOaKQRg0CI4Bl/wPL0xZYXnHI6TBIGl1opBXoBJ2D
7gYc1FwOuqZx0L2Cg9rM8RTeQcfe/oSZtKxBNyUNCELcPAXnHGJia0BXtwnP5MtcOlclfuRDRb7B
hOPxzQBf6Epvj1//+LrVD64qrVj/2Hpw2RPequXTm5bVpXurl09vXF7nF/6y6uSVzZN2HVsHngLe
0bR3YUXJgr0tU/b2VJTM3wvbHBq6RXoVtqH7oj10X5ReSh9R0EkYLHsJDcuTOITsLhjBX0TcTrYl
kjdH8gkH2x19456oyTL9W/dE37QlGjUeuY98+5boO/Oz62oimaNGnMPptalzpra05S08QLdExfKW
qCFUt622qrMsWfjbpqf3TbZklASGqvhOSPE3DC48vtBrt46pynFO3X9kY/3lfZX2nNrCoTvw7L9v
R2K2FB+GtYpJ77E144SgOWEisGwZMDMVFdSGZmoqG4ngRk/olEeok5BkWDArog1PCZqd/iYnXZBh
5UXHEN3nyEt7Onq4C9BV++gp6ismUYkPiyqtRuNOzXQmjR03PjDKDvLMk1UzviLVmJ6ZalBIgrTQ
lWbVarUaR/7UssEYn3EuDZt9pXUhs6TR6bQmL21x2/A58QW0uIm8EDEUNFc3T2/e3XykWTnqKEx2
EjmMUQA+fRStlcMYGjJjONQMCG9GfOw8jM4wXjq5JI7DkOylI8j7FP7Jgh6s6hAghgjisQA4HQmi
vGrDEYNoyH+rTPehtdXabV1jldix1xv0zGuK63223R458Eocd+EBGD9+lde2bNtE10IJ4/4/H3eJ
LxTP3ztt7Oz6sS6dgh5nhatnlY+pK/KGIq3RtkgoZ8b2GZmN43Ocagn3ep1Km1HaVDAmkuPMjsyI
zoyEBFP9CvS3O8mR6bMnW9Rev9cWKM0KlmT7MsJVsyrH9TTlGmxOi8HssliTLGpXksseGJsSGpft
zxhT2U77In347+JKxeNkPJl3LIdYA3nUyWAqmWFTsNwXYHkWkxlGxKbgi4jBbcw7F2hMNZ5zNxZi
R9mvls8nzp2lblfM7FJ09gzbZCvkx67Wry/mRadTPsLBohHnsPKZBA2LKzUWf06+u6EvkrrLbKNn
Xjv5EvI9eopjM79XNtmdmeLQKLVKxdzUDItJq8pqXj9NNLH19Wt4mKhQaA3q19TWZHumf0jXtUCr
0ypNHjI8TNst/V1ZgP8hwgYcz6oDInvaTuPfhD1qyMR4QQ1uTF8cC6elhTHmvowYpHHhmkZL+NyE
cY0OuoHOatGyDfTZc0XY78ibHRxhFdE9DnYgl2Yc7GtGWoYt37ebQnokzYW7vpsuAoYKRjXw260h
nfAmX7x9ZNQ5L7XTlppu/VajoO9voacO0tO4y38HZw4lgj5ER1GIjqKQBn0cktdWIXrnD6H9T7LZ
xpeYhsCyZ4C/kKdyKujKkmbgEZ+wCBhPa89rCumVSU1YaikvHT3QOYqvrkaG1TcePYzsL6zy/rm0
bCQChw62VKc71apquU2+masdbHfnLmgcW7W9HocPeIBh047c4zdHp1UuuWahmMFXQIOfTV9Qm9UR
FTfyGDo2MrAD2Q775JI/ncRjedyf6NLVp6GfWT4hjYk0Qd5moeHysyqwIzFz86WQLRG2wjCRMmQo
wzrBKoQsQrZSyMhGxMQMITNDSKcSTxsz0wW/HOsXMv1CyCxsShfSseuJaK3OxnQ/Zi6E3o9oMRWm
0/MOGqIbIPAnEQPKSM9uStcnN+nZTQD2lTctJNwlrwXCXV30T6CLAjkBj/Qh6OSlHnlYlDiFpqtT
u7vMzu6U0nZBlMShswpjcnZaWnaSSTH0gkIpaOw+d2oAz/iHFNIFEWdNXneaVS3dq9DqDOqLP6DP
8BUak06abbBpJWzzRHxoB5MNBvGvWuyzRY2eWnscziT2w9r15O2TeFRyOjIRTcOpotCSUy6UUc7K
F4LpQtAvBH1CME0IpgqhFCFbIeRIwvgJwoTxwoQ8oTIXr77iESX+xVreAlPG0SAi/CjBgnuoHE05
gudGLWYaba5pkvNRY1ZbpltWW3ZbFJaIzdVoKW7Kahp/Y66QS9Ny6Z3DYnc1LsndnCvWI9Y9VZ4B
XqWW7DpTXX0WlmT2lm1eOJZQK8umpiJhaGwKEw/lpJBafnOCPp/DSXdi/zjK5KOkcr9COfRvyejO
TvONSTJIPxTFI5IxOSfNF0Jo6Eulgs4cKRk2jfQ7UXxe1Nrg9j6bRnxdFF4T8QAr2YNXVaR71Q7z
pU4RD2q1g+svdZHZodbq0UPYew4ma7XoISNuPtigD3p4SNRgESqQHIyOZvRXAbnyJCmEYazwvAI6
b+TTGWNCvuCBPz4JWeIR3Im5gQ4VOcolaKm3jkEyoddUEqE8IJTqBb0fbq2nvaLXF47NaQroralN
fD9OZwurTaAvT8imFajZ6R8+8DqK/MAAppQuvY0CqyY2WXbZifHKilqQajX2kC8t4NQrfvu6Qu/M
wEspVkEreIb+rRHsIX9qwKFTnH1JobP6vKlZNlE79GWuyW5QYr+tFhYN3QmSlAa7STghPGyyGxWS
Sqce6hemgySF3mEemk9nD6yCd8A+mWTGSeJFW8ehmWVeIccreOhiPugRgqZSkxjSCsl0WTI+WUgq
B09IEnxNSTp7k65ZMZ00ywdr2Axh6KKV1JPo4E2X2DORMnswCM8pSbRRKLbThZzL5VCLxVtUhUXJ
fquo2qG1SEPPaCyZaWkZDq1SEKQvVNYMf0qmVTV03GJVGhwmoUJh00nznB6TEq/bGAfzxdfseiXu
lTas54l0Qj570uM9MwdezBPXHlNpJUMjqX77LOZueqA36sRHaOMnPENHFGcTBzpD/bBIvXBMzBcn
4k010zGi1p/D4yCsE86y6+nD+sTbL2K+zTo034Yf4Xt4zKUUvgyl+YLBNJU1mQjD/xLOKUT8X7WZ
WOMo5aSQghfdvrkghWi3X6y222x26VmtWasUcbiKd6ACWqu8Dr1HvEuarbwaHuyJmNKyfaECt9ps
Uen0AT0pKMAjFtQM7qJShUJ2F21hmV2tCoaCwbIyvGNWVlrqdkt416zIpZbKSl1ul0utlppMotud
ang1RfLn5/ullFcMaW63YPr0U5PgdqcZXuHxrxpS3W7R9Kn0sCoQyrZp7xw6b7Zgwaq6U2vLDgVU
ly1XB0Ihm/YOQWnBz9CFOxAfDKiXY7Ui4M0U9lagCm/akM6Omvb61nBtz4plC9ct+z/A3qhsCmVu
ZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKMTI4MzEKZW5kb2JqCjU0IDAgb2JqCihkYm91bmQucHB0
eCkKZW5kb2JqCjU1IDAgb2JqCihNYWMgT1MgWCAxMC45LjUgUXVhcnR6IFBERkNvbnRleHQpCmVu
ZG9iago1NiAwIG9iagooRGVjY2lvLCBDYXNleSkKZW5kb2JqCjU3IDAgb2JqCigpCmVuZG9iago1
OCAwIG9iagooUG93ZXJQb2ludCkKZW5kb2JqCjU5IDAgb2JqCihEOjIwMTQxMTE3MTkxNjU4WjAw
JzAwJykKZW5kb2JqCjYwIDAgb2JqCigpCmVuZG9iago2MSAwIG9iagpbICgpIF0KZW5kb2JqCjEg
MCBvYmoKPDwgL1RpdGxlIDU0IDAgUiAvQXV0aG9yIDU2IDAgUiAvU3ViamVjdCA1NyAwIFIgL1By
b2R1Y2VyIDU1IDAgUiAvQ3JlYXRvcgo1OCAwIFIgL0NyZWF0aW9uRGF0ZSA1OSAwIFIgL01vZERh
dGUgNTkgMCBSIC9LZXl3b3JkcyA2MCAwIFIgL0FBUEw6S2V5d29yZHMKNjEgMCBSID4+CmVuZG9i
agp4cmVmCjAgNjIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDkzMTM2IDAwMDAwIG4gCjAwMDAw
MDE3OTMgMDAwMDAgbiAKMDAwMDA3ODY5OSAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAw
MDAwMDE3NzMgMDAwMDAgbiAKMDAwMDAwMTg5NyAwMDAwMCBuIAowMDAwMDczMzUzIDAwMDAwIG4g
CjAwMDAwNzYxMjUgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDc4ODQ2IDAwMDAw
IG4gCjAwMDAwMDI2MTIgMDAwMDAgbiAKMDAwMDAxOTYzMSAwMDAwMCBuIAowMDAwMDIwOTE5IDAw
MDAwIG4gCjAwMDAwMjI2OTcgMDAwMDAgbiAKMDAwMDAwMjMxNCAwMDAwMCBuIAowMDAwMDIyNzE4
IDAwMDAwIG4gCjAwMDAwMjUwOTMgMDAwMDAgbiAKMDAwMDAyNTExNCAwMDAwMCBuIAowMDAwMDI1
OTEzIDAwMDAwIG4gCjAwMDAwMDI0NjIgMDAwMDAgbiAKMDAwMDAxOTY1MyAwMDAwMCBuIAowMDAw
MDIwODk4IDAwMDAwIG4gCjAwMDAwMjU5MzMgMDAwMDAgbiAKMDAwMDAyNjg5MSAwMDAwMCBuIAow
MDAwMDAyMTY4IDAwMDAwIG4gCjAwMDAwNzYxNjEgMDAwMDAgbiAKMDAwMDA3Njc0OCAwMDAwMCBu
IAowMDAwMDc3NzExIDAwMDAwIG4gCjAwMDAwNjA2MzIgMDAwMDAgbiAKMDAwMDA3MDM2NSAwMDAw
MCBuIAowMDAwMDcwMzg2IDAwMDAwIG4gCjAwMDAwNzIxNjEgMDAwMDAgbiAKMDAwMDAzNDIxOCAw
MDAwMCBuIAowMDAwMDUwMjU2IDAwMDAwIG4gCjAwMDAwNTAyNzggMDAwMDAgbiAKMDAwMDA1Mjkz
NSAwMDAwMCBuIAowMDAwMDI2OTExIDAwMDAwIG4gCjAwMDAwMzQxOTcgMDAwMDAgbiAKMDAwMDA1
Mjk1NiAwMDAwMCBuIAowMDAwMDYwNjExIDAwMDAwIG4gCjAwMDAwNzIxODIgMDAwMDAgbiAKMDAw
MDA3MzMzMiAwMDAwMCBuIAowMDAwMDczMzg5IDAwMDAwIG4gCjAwMDAwNzYxMDQgMDAwMDAgbiAK
MDAwMDA3NjcyOCAwMDAwMCBuIAowMDAwMDc3NjkxIDAwMDAwIG4gCjAwMDAwNzg2NzkgMDAwMDAg
biAKMDAwMDA3ODc4MiAwMDAwMCBuIAowMDAwMDc5NzExIDAwMDAwIG4gCjAwMDAwNzkxNDkgMDAw
MDAgbiAKMDAwMDA3OTY5MSAwMDAwMCBuIAowMDAwMDc5OTQ2IDAwMDAwIG4gCjAwMDAwOTI4Njgg
MDAwMDAgbiAKMDAwMDA5Mjg5MCAwMDAwMCBuIAowMDAwMDkyOTIwIDAwMDAwIG4gCjAwMDAwOTI5
NzIgMDAwMDAgbiAKMDAwMDA5MzAwNCAwMDAwMCBuIAowMDAwMDkzMDIzIDAwMDAwIG4gCjAwMDAw
OTMwNTIgMDAwMDAgbiAKMDAwMDA5MzA5NCAwMDAwMCBuIAowMDAwMDkzMTEzIDAwMDAwIG4gCnRy
YWlsZXIKPDwgL1NpemUgNjIgL1Jvb3QgNDggMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw1YjJhZTJj
NWU0OWU5ODgxYjAzYTg5NGEyOTdhMGRmNT4KPDViMmFlMmM1ZTQ5ZTk4ODFiMDNhODk0YTI5N2Ew
ZGY1PiBdID4+CnN0YXJ0eHJlZgo5MzMxMQolJUVPRgo=
--089e01228114ecd82e050812f81d--


From nobody Mon Nov 17 11:47:44 2014
Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D901A897B for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXPD7JeHPe-c for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 11:47:40 -0800 (PST)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CA11A8976 for <dbound@ietf.org>; Mon, 17 Nov 2014 11:47:40 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id i8so5837030qcq.39 for <dbound@ietf.org>; Mon, 17 Nov 2014 11:47:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u+WDvbfg3kBuPOEK4KTk+DpHzQhDZhFNo8kBOmHt3aE=; b=vgKxwqXOlt2JSuAjg6fgeK/lYRt8KAsJEUMHpvXipf7vel4D389/mNPK/wd3iFa24b JkBRf8iA8D0QTPdtu29aWUdn/L0QoNO560+P40DyqOtHosxy0ZTGAV72q4my9dNmESBK KJKXjEtfGLTVzdOLRNwqNBcjDl7sEAoD8fQoJPzWbyys0/fCSsxSn5U/8fNKPc/vGIsX HOhU8MK5IbxsgWkKKmsF543C8yV5S49JZyk6ZDWpZKFavKPeyFke8ZJM7jf7Jem8W2+S MxZNOhPG57fEK7MlWOTLh4wHlFU5s6aIU8kQiu1embzpju9nhOrUAB/WyptYgqNq5Hkk 4RaQ==
X-Received: by 10.224.60.196 with SMTP id q4mr37422645qah.63.1416253659226; Mon, 17 Nov 2014 11:47:39 -0800 (PST)
Received: from twicinski-ltm.internal.salesforce.com ([204.14.236.215]) by mx.google.com with ESMTPSA id b20sm5668039qaw.3.2014.11.17.11.47.38 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 11:47:38 -0800 (PST)
Message-ID: <546A50D8.3@gmail.com>
Date: Mon, 17 Nov 2014 11:47:36 -0800
From: Tim Wicinski <tjw.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>, dbound@ietf.org
References: <546A4636.4050502@KingsMountain.com>
In-Reply-To: <546A4636.4050502@KingsMountain.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/-VL-b69vZrWTfUlE6X0z2MqEeSs
Subject: Re: [Dbound] commands to get TLD list (was: multiple PSL-equivalents exist..
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 19:47:41 -0000

Or for us very lazy one-liner types:

curl -s http://www.internic.net/domain/root.zone  | awk '$4 == "NS" { 
print $1 }' | sed 's/\.$//' | sort -u



On 11/17/14 11:02 AM, =JeffH wrote:
> Casey supplied..
>
>  > awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u >
> tlds.txt
>
> cool, thx. tho one needs to do this first to get the root.zone file..
>
> wget http://www.internic.net/domain/root.zone
> awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u >
> tlds.txt
>
> [see also: https://www.iana.org/domains/root/files ]
>
>
> results:
>
>  > head -20 tlds.txt
>
> abogado
> ac
> academy
> accountants
> active
> actor
> ad
> ae
> aero
> af
> ag
> agency
> ai
> airforce
> al
> allfinanz
> alsace
> am
> an
> ...
>
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


From nobody Mon Nov 17 13:50:40 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B191ACD24 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 13:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItHhOxMb4uU5 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 13:50:37 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6691ACD1F for <dbound@ietf.org>; Mon, 17 Nov 2014 13:50:37 -0800 (PST)
Received: (qmail 16979 invoked from network); 17 Nov 2014 21:50:36 -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=4252.546a6dac.k1411; bh=5o1awY9Wed7EjmGe1L5c5pBgInisK2B5QwbR3t9Smtg=; b=dWR7Z37SrF0cQOAjTuNezuCIY56iTXImYpYwspR77zUM+fZREGtzoeZ2pf7JMikblX9Pz5lSu+rLkwMo5+/6UQnZraoqtJd4DGiR3CUUV8xrJ+kGpI9Bn1C3oRaWhg0vwCrYWk82zSZ1ukJO9N/rS4M5fs8ym+MXHJ2ojHahx+zY9B1pSz3G1rKBkaI7U1D/ZxVOghmE6oBjZXdXhtQqmbkYOi5myJSIrWlYj1I0nAU0PFSbMqD9n2uOK/WyP95f
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=4252.546a6dac.k1411; bh=5o1awY9Wed7EjmGe1L5c5pBgInisK2B5QwbR3t9Smtg=; b=fVmqjnyRt61Q9zkiq51c72A6/IUi/yeBfMKgH1rgnmmFJ4YLvr8+t4/nDDmdhn5NZTnG2AgLa3fk2oR6XuUT6H6tCKfBsnpGZXKDocs9JJUnj0H1kitkTFnUdUrhSfXjLyDBZEMOEBwNVvMiQyJpX9rw5Csl+305bjbMBf1yM5bWeAHbuI8TsWyHf6nK8zWS/Ob7rnEaX0JVQKBfJ7VenpmtgYSx7/p0RSqsKPYK45WkKAMMGUJnRbZV/WFmXr9d
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; 17 Nov 2014 21:50:36 -0000
Date: 17 Nov 2014 16:50:35 -0500
Message-ID: <alpine.OSX.2.11.1411171643500.18601@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Casey Deccio" <casey@deccio.net>
In-Reply-To: <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/4KHJaP4hPjOnz6Y41Bt0B4HJ6II
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 21:50:39 -0000

> That being said, I had proposed that the problem of identifying domain
> relationships and boundaries was broken up into several areas, one of which
> was "cross-scope" ...

Honestly, I saw your chart, but I didn't understand it.

Every application I've seen for the PSL asks one of these three questions:

* Are names A and B under the same authority? (the cookie question)

* Are all the names covered by this wildcard under the same authority? (the cert question)

* What's the shortest* name under the same authority as this one? (the DMARC question)

None of those answers seem to me to make any sort of public/private 
distinction.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

* - shortest by number of components, e.g., foo.org is shorter than bar.foo.org


From nobody Mon Nov 17 14:01:54 2014
Return-Path: <rob.stradling@comodo.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDDB1ACD43 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 14:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAz7xAjThxts for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 14:01:44 -0800 (PST)
Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 3D0FF1ACD49 for <dbound@ietf.org>; Mon, 17 Nov 2014 14:01:36 -0800 (PST)
Received: (qmail 31497 invoked by uid 1004); 17 Nov 2014 22:01:34 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 17 Nov 2014 22:01:34 +0000
Received: (qmail 17484 invoked by uid 1000); 17 Nov 2014 22:01:34 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 17 Nov 2014 22:01:34 +0000
Message-ID: <546A703D.4000808@comodo.com>
Date: Mon, 17 Nov 2014 22:01:33 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>
References: <54656E05.7060608@KingsMountain.com><44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu><544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><5469BF3D.7020300@comodo.com> <4333A7B2-483F-424B-8ED2-77E0A5110373@anvilwalrusden.com>
In-Reply-To: <4333A7B2-483F-424B-8ED2-77E0A5110373@anvilwalrusden.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/2eE9EAYE7JWwKNZcT1hHunmY7SA
Cc: manning bill <bmanning@isi.edu>, Rick Andrews <Rick_Andrews@symantec.com>, =JeffH <Jeff.Hodges@KingsMountain.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was:algorithmicbackground material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 22:01:52 -0000

On 17/11/14 17:02, Andrew Sullivan wrote:
> This is interesting (good) news, because the claim about CAs maintaining a list of changes to the PSL that we added to the SOPA draft was inspired by a remark Phill Hallam-Baker made at a mic.

Hi Andrew.  I asked Phill to comment.  He thought you might be getting 
mixed up with this requirement from the CABForum BRs...

   "11.5 High Risk Requests
    The CA SHALL develop, maintain, and implement documented procedures
    that identify and require additional verification activity for High
    Risk Certificate Requests prior to the Certificate’s approval, as
    reasonably necessary to ensure that such requests are properly
    verified under these Requirements."

Each CA tends to have their own home grown list of "hot domains" to 
address this requirement.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Mon Nov 17 14:08:49 2014
Return-Path: <R.E.Sonneveld@sonnection.nl>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8A11ACD7D for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 14:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASA74zhTc75G for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 14:08:32 -0800 (PST)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E91ACD71 for <dbound@ietf.org>; Mon, 17 Nov 2014 14:08:22 -0800 (PST)
Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3jhPYd50RSz1L8cw; Mon, 17 Nov 2014 23:08:21 +0100 (CET)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3jhPYd3SmQz1L8cr; Mon, 17 Nov 2014 23:08:21 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 6166D12335F; Mon, 17 Nov 2014 23:08:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CnTJMe0mJDjy; Mon, 17 Nov 2014 23:08:11 +0100 (CET)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 81D9E122EBB; Mon, 17 Nov 2014 23:08:11 +0100 (CET)
Message-ID: <546A71C7.6040903@sonnection.nl>
Date: Mon, 17 Nov 2014 23:08:07 +0100
From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl>
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Rob Stradling <rob.stradling@comodo.com>,  Andrew Sullivan <ajs@anvilwalrusden.com>
References: <54656E05.7060608@KingsMountain.com><44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu><544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><5469BF3D.7020300@comodo.com> <4333A7B2-483F-424B-8ED2-77E0A5110373@anvilwalrusden.com> <546A703D.4000808@comodo.com>
In-Reply-To: <546A703D.4000808@comodo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1416262101; bh=HcdEC9p+xEjBtTedadEqXz8voZXH+Z800sgBZ7jmJFk=; h=Message-ID:Date:From:To:Subject:From; b=fXNLOSeH8/UOaV9PfR1twLUYc4673BfBE5rXC0Ke1EJROwSvNZ5H7q3PkgeDP+aLy mwqXuni+xLl8dRR1ebsjofLdT6i30zYSRhNRUYmReMXbp+j4dnDOqOAGUtaR4q3cFm 4mK5RvU2CISjdZC5dDi1c1wUmH+g1+GSlgi8ngxg=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3jhPYd50RSz1L8cw
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TorfIPfOx9bvAAO_4awKuuN49R4
Cc: "dbound@ietf.org" <dbound@ietf.org>, =JeffH <Jeff.Hodges@KingsMountain.com>, Rick Andrews <Rick_Andrews@symantec.com>, manning bill <bmanning@isi.edu>
Subject: Re: [Dbound] multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: R.E.Sonneveld@sonnection.nl
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 22:08:44 -0000

On 11/17/2014 11:01 PM, Rob Stradling wrote:
> On 17/11/14 17:02, Andrew Sullivan wrote:
>> This is interesting (good) news, because the claim about CAs=20
>> maintaining a list of changes to the PSL that we added to the SOPA=20
>> draft was inspired by a remark Phill Hallam-Baker made at a mic.
>
> Hi Andrew.  I asked Phill to comment.  He thought you might be getting=20
> mixed up with this requirement from the CABForum BRs...
>
>   "11.5 High Risk Requests
>    The CA SHALL develop, maintain, and implement documented procedures
>    that identify and require additional verification activity for High
>    Risk Certificate Requests prior to the Certificate=E2=80=99s approva=
l, as
>    reasonably necessary to ensure that such requests are properly
>    verified under these Requirements."
>
> Each CA tends to have their own home grown list of "hot domains" to=20
> address this requirement.

wouldn't it be, uhm, strange, if CA's would trust some 3rd party to=20
provide this information?

/rolf


From nobody Mon Nov 17 18:04:22 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00721AD045 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 18:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.323
X-Spam-Level: *
X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ModymQ-7W4h9 for <dbound@ietfa.amsl.com>; Mon, 17 Nov 2014 18:04:12 -0800 (PST)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC2D1AD03B for <dbound@ietf.org>; Mon, 17 Nov 2014 18:04:10 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id gm9so2687153lab.32 for <dbound@ietf.org>; Mon, 17 Nov 2014 18:04:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fsWhl7pxsdhI+SkKQJLjCvOVTEju5/j9Zd2sKRvPBIA=; b=GLyGNm5j9n7kGHVKi2gisnctYmWlP08Bi3b/l4v1ey/l8TPch5dus4GN7kTdr2hoqY c5W3oEaJdYUey/bjNLB9XZCvT9GvBh+4tfoO1l+KaaYksh/PwykfHW3vV3z0RN+cbbnY 0rtZVnmKIGQyEBWf40aTSncS2Vxs8pAjz1yMa9HZ42GYRR1PVzDJqT1dUgRR62qOhDWl RQDbMlJ8Kjmx5OOyFGub1uOelYpMqs4+Y36OMLK9TkUGi7DBxtae51sDh7MuCPlFKxVR v0xdSPiuqi3xpG2P8e2/CAxe23wbZzOi28UjzxIiRmCZfpRmOAvkt6cS9jPo/FAnHN1O JGcA==
X-Gm-Message-State: ALoCoQnKsTbu8Pfo6mMAD91TbYXSUs9LKsNqVuGxxJTGze+d+EP3zpzcYLJXFsa/E5JswAEPbxu5
X-Received: by 10.152.5.100 with SMTP id r4mr32326563lar.26.1416276248617; Mon, 17 Nov 2014 18:04:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.89.21 with HTTP; Mon, 17 Nov 2014 18:03:38 -0800 (PST)
In-Reply-To: <CAEKtLiRw=2D+_ucttCfM=8T_PHMBRaCPhecoBe3jA0OG7FK43A@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <CAEKtLiRw=2D+_ucttCfM=8T_PHMBRaCPhecoBe3jA0OG7FK43A@mail.gmail.com>
From: Jothan Frakes <jothan@jothan.com>
Date: Mon, 17 Nov 2014 18:03:38 -0800
Message-ID: <CAGrS0FLWo5=m=SoFSjYjTtVZLBweLvHSXH_ZG=gEKpjwMxuovA@mail.gmail.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: multipart/alternative; boundary=089e0141a358b3fa240508188263
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/XV42F-M6cPyGWiITP10HGUipW4s
Cc: "Jeremy.Rowley" <jeremy.rowley@digicert.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist (was: algorithmic background material for BoF
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 02:04:19 -0000

--089e0141a358b3fa240508188263
Content-Type: text/plain; charset=UTF-8

Hi Casey-

On Mon, Nov 17, 2014 at 9:49 AM, Casey Deccio <casey@deccio.net> wrote:

>
> The IANA list of TLDs is just that--a complete list of TLDs delegated from
> the IANA root.  It can be generated from the root zone with the following:
>
>
Right, to us it does.  We live and breathe domain names - I am saying that
to a developer breaking ground on solving something like bozo filtering
invalid domains would use something in a caveman simple manner.  A
hypothetical of this would be using it to filter the rightmost element of
the FQDN in form validation of an email field, or URL entry field to solve
a form validation problem.    Example:   user enters foo@bar.xh ->
validation fails that because xh wasn't in IANA PSL

Often, a developer is working to solve tactical problems, like in rapid
development or scrum, these are chopped up into stories.  Often, they are
going to look for the fastest way through the maze to the cheese on solving
a tactical need.  This is just like a coder in the 70's or 80's not knowing
better may have used a two digit year field before y2k, or another example
I use frequently is where a coder used a numeric integer field or
constrained numeric only 5 character fields for zip codes and then
face-palmed when they realized much of the rest of the planet uses alpha
numeric six characters for postal codes.

When the coder sees they needed to do something with a little more finesse,
they then do it, but it takes awareness of it.  We have that awareness -
not everyone does.



> awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u >
> tlds.txt
>
>
Thank you for that shell scripting lesson, which I will take as intended as
offered in sincere kindness without awareness my background with your
employer.    :)


> If folks are using that list, it tells me several things:
>
> 1. They are interested in only top-level domains.
>

Well I also find that when I am asked about an approach that helps solve a
coding challenge, often they don't know what they don't know about what
nuances are present underneath ... which is also common.
Like legacy RFC 1480 _stuff_ under .US

or the RFC 6761 .TEST etc _stuff_ that would still be invalid but not be
present in any PSL while .ARPA might

And then drafts like this happen here in IETF:
http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-02
(since expired)



> 2. Unless their definition of "public" is limited to TLDs, then they are
> getting an incomplete list.
>

Amen, but still that quick-pass invalid filter hypothetical would still
function for their needs


> 3. Unless their definition of "public" considers that some TLDs might not
> actually be public (not just speaking about HTTP cookies), their list might
> include too much (the Mozilla PSL suffers from this as well).
>

I agree and that is an important point to not just be speaking about
cookies, which has a distinct need from that example I just gave


> 4. This list can be derived from the root zone, either completely (e.g.,
> by the command above) or selectively (e.g., by issuing simple one-label
> queries to the root servers).
>

No doubt about that.



> That doesn't mean the list isn't useful to some, but simply that I don't
> see it adding anything new to the root zone, either in terms of maintenance
> or accessibility.  However, I'm interested to learn if I've missed
> something and/or if folks are in fact using this list as some sort of PSL
> equivalent/replacement.
>
>

Right, so what happens is that people start with the IANA TLD List "PSL" or
the awk sed sort root zone as a starting point.


>
>> Even if the definition is the former, it does still qualify, but as a
>> subset of larger more detailed lists.  The IANA TLD list is really somewhat
>> of patient zero upon which most other lists are derived.
>>
>
> Let me be more clear about what I am asking.  DBOUND is working on a
> problem statement, which, in part, should reflect demand and use cases for
> learning relationships (or boundaries) between different domains--if it is
> to be useful.  As there is some precedent, embodied in the Mozilla Public
> Suffix List (PSL), it is useful to understand PSL use cases--not as the
> only problem or solution, but as concrete examples of real use, both in
> browsers and other applications.  The Mozilla PSL is not merely a list of
> TLDs extracted from the root zone, but maintains nearly 7,000 entries,
> delineating a "public" (for some definition of public) boundary in the DNS
> namespace.  While it can likely be agreed that it is not a perfect or
> comprehensive solution, nor does it address the general problem of domain
> relationships--only boundaries--it is well used, and represents a
> non-trivial compilation and effort.
>
> Now my question: it has been suggested that there are other lists being
> maintained and consumed in *like* manner.  Can some lists and use cases be
> positively identified?
>


http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

Looking for a few - many / most are now in the realm of internal /
proprietary and are not shared, the others like these examples have fallen
into atrophy, though on Greasemonkey you can see the wiki history:
http://www.neuhaus.com/domaincheck/domain_list.htm
http://www.tld-resource.com/tldinfo.php
http://wiki.greasespot.net/index.php?title=Magic_TLD


>
> Lists and use cases - that's what we're looking for.
>
>
>> ...
>> I have some asks out to some of the integrators and developers who have
>> reached out to me over the course of the past 8 or so years of my volunteer
>> time with Mozilla about their PSL effort to also describe use cases.
>>
>
> Thanks!
>
>
There is a section from a support document in another group you and I are
participating in that I put some effort into accumulating, I will get that
together with some responses from folks once they come in from LEA,
Developers, Whois services and others and do it as a fresh email so its not
buried in a thread.  Will take a few weeks to put together.

-J

--089e0141a358b3fa240508188263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
ure"><div>Hi Casey-</div></div></div>
<br><div class=3D"gmail_quote">On Mon, Nov 17, 2014 at 9:49 AM, Casey Decci=
o <span dir=3D"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blan=
k">casey@deccio.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D""><div><br></div></span><div>The IANA list of TLDs is just that--a comp=
lete list of TLDs delegated from the IANA root.=C2=A0 It can be generated f=
rom the root zone with the following:<br><br></div></div></div></div></div>=
</blockquote><div><br></div><div>Right, to us it does.=C2=A0 We live and br=
eathe domain names - I am saying that to a developer breaking ground on sol=
ving something like bozo filtering invalid domains would use something in a=
 caveman simple manner.=C2=A0 A hypothetical of this would be using it to f=
ilter the rightmost element of the FQDN in form validation of an email fiel=
d, or URL entry field to solve a form validation problem. =C2=A0 =C2=A0Exam=
ple: =C2=A0 user enters foo@bar.xh -&gt; validation fails that because xh w=
asn&#39;t in IANA PSL</div><div><br></div><div>Often, a developer is workin=
g to solve tactical problems, like in rapid development or scrum, these are=
 chopped up into stories.=C2=A0 Often, they are going to look for the faste=
st way through the maze to the cheese on solving a tactical need.=C2=A0 Thi=
s is just like a coder in the 70&#39;s or 80&#39;s not knowing better may h=
ave used a two digit year field before y2k, or another example I use freque=
ntly is where a coder used a numeric integer field or constrained numeric o=
nly 5 character fields for zip codes and then face-palmed when they realize=
d much of the rest of the planet uses alpha numeric six characters for post=
al codes.</div><div><br></div><div>When the coder sees they needed to do so=
mething with a little more finesse, they then do it, but it takes awareness=
 of it.=C2=A0 We have that awareness - not everyone does.</div><div><br></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div>awk &#39;$4 =3D=3D &quot;NS&quot=
; { print $1 }&#39; root.zone | sed &#39;s/\.$//&#39; | sort -u &gt; tlds.t=
xt<br><br></div></div></div></div></div></blockquote><div><br></div><div>Th=
ank you for that shell scripting lesson, which I will take as intended as o=
ffered in sincere kindness without awareness my background with your employ=
er. =C2=A0 =C2=A0:)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div=
>If folks are using that list, it tells me several things:<br><br></div><di=
v>1. They are interested in only top-level domains.<br></div></div></div></=
div></div></blockquote><div><br></div><div>Well I also find that when I am =
asked about an approach that helps solve a coding challenge, often they don=
&#39;t know what they don&#39;t know about what nuances are present underne=
ath ... which is also common.</div><div>Like legacy RFC 1480 _stuff_ under =
.US</div><div><br></div><div>or the RFC 6761 .TEST etc _stuff_ that would s=
till be invalid but not be present in any PSL while .ARPA might=C2=A0</div>=
<div><br></div><div>And then drafts like this happen here in IETF:</div><di=
v><a href=3D"http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p=
-names-02">http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-n=
ames-02</a> (since expired)<br></div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>2. Unless their definition of &quot;public&quot; is limite=
d to TLDs, then they are getting an incomplete list.<br></div></div></div><=
/div></div></blockquote><div><br></div><div>Amen, but still that quick-pass=
 invalid filter hypothetical would still function for their needs</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div></div><div>3. Unless their definition o=
f &quot;public&quot; considers that some TLDs might not actually be public =
(not just speaking about HTTP cookies), their list might include too much (=
the Mozilla PSL suffers from this as well).<br></div></div></div></div></di=
v></blockquote><div><br></div><div>I agree and that is an important point t=
o not just be speaking about cookies, which has a distinct need from that e=
xample I just gave</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>=
4. This list can be derived from the root zone, either completely (e.g., by=
 the command above) or selectively (e.g., by issuing simple one-label queri=
es to the root servers).<br></div></div></div></div></div></blockquote><div=
><br></div><div>No doubt about that. =C2=A0</div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div>That doesn&#39;t mean the list isn&#39;t usefu=
l to some, but simply that I don&#39;t see it adding anything new to the ro=
ot zone, either in terms of maintenance or accessibility.=C2=A0 However, I&=
#39;m interested to learn if I&#39;ve missed something and/or if folks are =
in fact using this list as some sort of PSL equivalent/replacement.<br><br>=
</div></div></div></div></div></blockquote><div><br></div><div><br></div><d=
iv>Right, so what happens is that people start with the IANA TLD List &quot=
;PSL&quot; or the awk sed sort root zone as a starting point.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div></div><span class=3D""><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v><br></div><div>Even if the definition is the former, it does still qualif=
y, but as a subset of larger more detailed lists.=C2=A0 The IANA TLD list i=
s really=C2=A0somewhat of patient zero upon which most other lists are deri=
ved.=C2=A0=C2=A0=C2=A0</div></blockquote><div><br></div></span><div>Let me =
be more clear about what I am asking.=C2=A0 DBOUND is working on a problem =
statement, which, in part, should reflect demand and use cases for learning=
 relationships (or boundaries) between different domains--if it is to be us=
eful.=C2=A0 As there is some precedent, embodied in the Mozilla Public Suff=
ix List (PSL), it is useful to understand PSL use cases--not as the only pr=
oblem or solution, but as concrete examples of real use, both in browsers a=
nd other applications.=C2=A0 The Mozilla PSL is not merely a list of TLDs e=
xtracted from the root zone, but maintains nearly 7,000 entries, delineatin=
g a &quot;public&quot; (for some definition of public) boundary in the DNS =
namespace.=C2=A0 While it can likely be agreed that it is not a perfect or =
comprehensive solution, nor does it address the general problem of domain r=
elationships--only boundaries--it is well used, and represents a non-trivia=
l compilation and effort.<br><br>Now my question: it has been suggested tha=
t there are other lists being maintained and consumed in *like* manner.=C2=
=A0 Can some lists and use cases be positively identified?<br></div></div><=
/div></div></div></blockquote><div><br><br></div><div><a href=3D"http://en.=
wikipedia.org/wiki/List_of_Internet_top-level_domains">http://en.wikipedia.=
org/wiki/List_of_Internet_top-level_domains</a>=C2=A0<br></div><div><br>Loo=
king for a few - many / most are now in the realm of internal / proprietary=
 and are not shared, the others like these examples have fallen into atroph=
y, though on Greasemonkey you can see the wiki history:<br><a href=3D"http:=
//www.neuhaus.com/domaincheck/domain_list.htm">http://www.neuhaus.com/domai=
ncheck/domain_list.htm</a><br><a href=3D"http://www.tld-resource.com/tldinf=
o.php">http://www.tld-resource.com/tldinfo.php</a><br></div><div><a href=3D=
"http://wiki.greasespot.net/index.php?title=3DMagic_TLD">http://wiki.grease=
spot.net/index.php?title=3DMagic_TLD</a><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>=C2=A0</div></div><div class=3D"gmail_quote"><div>Lists and =
use cases - that&#39;s what we&#39;re looking for.=C2=A0</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div>...<br></div><span class=3D""><div>I have some as=
ks out to some of the integrators and developers who have reached out to me=
 over the course of the past 8 or so years of my volunteer time with=C2=A0M=
ozilla about their PSL=C2=A0effort to also describe use cases.</div></span>=
</blockquote><div><br></div><div>Thanks!<br><br></div></div></div></div></d=
iv></blockquote><div><br></div><div>There is a section from a support docum=
ent in another group you and I are participating in that I put some effort =
into accumulating, I will get that together with some responses from folks =
once they come in from LEA, Developers, Whois services and others and do it=
 as a fresh email so its not buried in a thread.=C2=A0 Will take a few week=
s to put together.</div><div><br></div><div>-J</div></div></div></div>

--089e0141a358b3fa240508188263--


From nobody Tue Nov 18 01:04:26 2014
Return-Path: <gavin.brown@centralnic.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5731A007F for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 01:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cyGhwhRdRwz for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 01:04:16 -0800 (PST)
Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (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 B87CB1A0041 for <dbound@ietf.org>; Tue, 18 Nov 2014 01:04:14 -0800 (PST)
Received: from Gavins-MacBook-Pro.local (unknown [90.202.47.183]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 33AC29E90; Tue, 18 Nov 2014 09:04:12 +0000 (UTC)
Message-ID: <546B0B8B.6000703@centralnic.com>
Date: Tue, 18 Nov 2014 09:04:11 +0000
From: Gavin Brown <gavin.brown@centralnic.com>
Organization: CentralNic Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tim Wicinski <tjw.ietf@gmail.com>
References: <546A4636.4050502@KingsMountain.com> <546A50D8.3@gmail.com>
In-Reply-To: <546A50D8.3@gmail.com>
OpenPGP: id=F923B4CE
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EUuvLwnQibV1dOkaJIII4BvGD3CsRMmLf"
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/NTRkAT8y9NmdRt9p89LapDLPuuU
Cc: dbound@ietf.org
Subject: Re: [Dbound] commands to get TLD list (was: multiple PSL-equivalents exist..
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 09:04:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EUuvLwnQibV1dOkaJIII4BvGD3CsRMmLf
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

IANA publishes a flat list of TLDs:

https://data.iana.org/TLD/tlds-alpha-by-domain.txt

On 17/11/2014 19:47, Tim Wicinski wrote:
>=20
> Or for us very lazy one-liner types:
>=20
> curl -s http://www.internic.net/domain/root.zone  | awk '$4 =3D=3D "NS"=
 {
> print $1 }' | sed 's/\.$//' | sort -u
>=20
>=20
>=20
> On 11/17/14 11:02 AM, =3DJeffH wrote:
>> Casey supplied..
>>
>>  > awk '$4 =3D=3D "NS" { print $1 }' root.zone | sed 's/\.$//' | sort =
-u >
>> tlds.txt
>>
>> cool, thx. tho one needs to do this first to get the root.zone file..
>>
>> wget http://www.internic.net/domain/root.zone
>> awk '$4 =3D=3D "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u =
>
>> tlds.txt
>>
>> [see also: https://www.iana.org/domains/root/files ]
>>
>>
>> results:
>>
>>  > head -20 tlds.txt
>>
>> abogado
>> ac
>> academy
>> accountants
>> active
>> actor
>> ad
>> ae
>> aero
>> af
>> ag
>> agency
>> ai
>> airforce
>> al
>> allfinanz
>> alsace
>> am
>> an
>> ...
>>
>>
>> _______________________________________________
>> Dbound mailing list
>> Dbound@ietf.org
>> https://www.ietf.org/mailman/listinfo/dbound
>=20
>=20

--=20
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.


--EUuvLwnQibV1dOkaJIII4BvGD3CsRMmLf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iEYEARECAAYFAlRrC4sACgkQ6H45IPkjtM4QmwCfe/s5SKHxFz4FHh4qen/2ruJ/
FsUAn0/mvUNvfpNVgDDkMOablC5TSUe9
=8KtP
-----END PGP SIGNATURE-----

--EUuvLwnQibV1dOkaJIII4BvGD3CsRMmLf--


From nobody Tue Nov 18 05:40:16 2014
Return-Path: <rob.stradling@comodo.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2091A039F for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 05:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz8CdZKVU8wA for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 05:40:11 -0800 (PST)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 602411A03A7 for <dbound@ietf.org>; Tue, 18 Nov 2014 05:40:11 -0800 (PST)
Received: (qmail 20068 invoked by uid 1004); 18 Nov 2014 13:40:08 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Ma, 18 nov 2014 13:40:08 +0000
Received: (qmail 24487 invoked by uid 1000); 18 Nov 2014 13:40:08 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 18 Nov 2014 13:40:08 +0000
Message-ID: <546B4C37.3020007@comodo.com>
Date: Tue, 18 Nov 2014 13:40:07 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: R.E.Sonneveld@sonnection.nl, Andrew Sullivan <ajs@anvilwalrusden.com>
References: <54656E05.7060608@KingsMountain.com><44AFFB45-F924-49A2-8EFB-FDD7FB99ACAB@isi.edu><544B0DD62A64C1448B2DA253C011414607D6B4E1F7@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><5469BF3D.7020300@comodo.com><4333A7B2-483F-424B-8ED2-77E0A5110373@anvilwalrusden.com><546A703D.4000808@comodo.com> <546A71C7.6040903@sonnection.nl>
In-Reply-To: <546A71C7.6040903@sonnection.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/FuuPgf7Y3L15BG5Z4ZPJTKiHoHk
Cc: manning bill <bmanning@isi.edu>, Rick Andrews <Rick_Andrews@symantec.com>, =JeffH <Jeff.Hodges@KingsMountain.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 13:40:15 -0000

On 17/11/14 22:08, Rolf E. Sonneveld wrote:
> On 11/17/2014 11:01 PM, Rob Stradling wrote:
>> On 17/11/14 17:02, Andrew Sullivan wrote:
>>> This is interesting (good) news, because the claim about CAs
>>> maintaining a list of changes to the PSL that we added to the SOPA
>>> draft was inspired by a remark Phill Hallam-Baker made at a mic.
>>
>> Hi Andrew.  I asked Phill to comment.  He thought you might be getting
>> mixed up with this requirement from the CABForum BRs...
>>
>>   "11.5 High Risk Requests
>>    The CA SHALL develop, maintain, and implement documented procedures
>>    that identify and require additional verification activity for High
>>    Risk Certificate Requests prior to the Certificate’s approval, as
>>    reasonably necessary to ensure that such requests are properly
>>    verified under these Requirements."
>>
>> Each CA tends to have their own home grown list of "hot domains" to
>> address this requirement.
>
> wouldn't it be, uhm, strange, if CA's would trust some 3rd party to
> provide this information?

Yes, I think it would be strange.  However, I think we're drifting 
off-topic...unless...

Could DBOUND specify an "evil bit" so that we can easily recognize dodgy 
domains ?  ;-)

http://en.wikipedia.org/wiki/Evil_bit

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Tue Nov 18 07:16:33 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0D31A1A36 for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 07:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfB-3YIX0rWU for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 07:16:14 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476801A1A28 for <dbound@ietf.org>; Tue, 18 Nov 2014 07:16:14 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id tr6so5250301ieb.15 for <dbound@ietf.org>; Tue, 18 Nov 2014 07:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r4beWQujITzTkd2QvQTQeBgsDg7FsOUtd9N6nD9YDZ0=; b=Xu6Rr5hfpXLLuhCP5OgklPUoEuRi6rl9vE88uIMctqN8QaWdPTsnMBBddE9BMvj6IM zTcbH8Hw7tcSarY9iQtEKPfVyxVHH60lg+2u4gdK5iw094AA8yVhgZh9PmyL60JmiBK6 NSgf6iL719IezLdRtxC5KCN6TUaF1RZ5DOOlE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r4beWQujITzTkd2QvQTQeBgsDg7FsOUtd9N6nD9YDZ0=; b=Zn+t80Bli05cpF689YdWiSwQvSMTrqCg4kkOc2NgdgZtKPVKhjELxEtj1wuqlfdMHu 78OCw+4KHwEbzKN0ttpgp3LWbLwwXnOm9ty8YpqUrl77UaU1ecePrTS1uFvI8Q3SbZQN eUejfNaAQyMA5rKvAwiq7GVCvNfEDLGd5eJqvsFN9wCYF+zlr9Nv7Iu4UZL42QM31W5q bWjU6NejiGFE63frpdE6uieiTJd8E2um86PQHuH0/G3Jx0osRRE5TKVTua+VdtpBQgm0 M+YNJzbepNKGkmIY3ndu0I4tji6XkjwBxFbdQmq/+jYrG9n7frYtSjYp9PHCB/Q981cf gBJQ==
X-Gm-Message-State: ALoCoQn0qS1D36mmI1kR3zpVCydU+xE9k4MBhCNFN2DkJg1Ign91rvRpFv76r49tbpXBVf2XVwoZ
MIME-Version: 1.0
X-Received: by 10.42.96.198 with SMTP id k6mr34298831icn.7.1416323773390; Tue, 18 Nov 2014 07:16:13 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 18 Nov 2014 07:16:13 -0800 (PST)
In-Reply-To: <alpine.OSX.2.11.1411171643500.18601@ary.lan>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com> <alpine.OSX.2.11.1411171643500.18601@ary.lan>
Date: Tue, 18 Nov 2014 10:16:13 -0500
Message-ID: <CAEKtLiSN9VNEF+4rgECsfe=rkXdD-AggTMGzNtX9a4teKRjWRA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=20cf303ea6306695db05082393a8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oQilIOsAmZSEilxm4Ec1Cixtd-Q
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 15:16:23 -0000

--20cf303ea6306695db05082393a8
Content-Type: text/plain; charset=UTF-8

Hi John,

On Mon, Nov 17, 2014 at 4:50 PM, John R Levine <johnl@taugh.com> wrote:
>>
>> That being said, I had proposed that the problem of identifying domain
>> relationships and boundaries was broken up into several areas, one of
which
>> was "cross-scope" ...
>
>
> Honestly, I saw your chart, but I didn't understand it.


The tree map represents a breakdown of comparison characteristics for
domain names, for the purposes of determining whether the two can be
positively associated (i.e., for some application).  Think of it like a
decision tree, where the area of each subdivision in the map represents the
likelihood that the branch will be followed.  The tree looks something like
this (note that this is considered a work-in-progress and not a definitive
model):

cross scope?
     |\
     |  yes -> "no positive association, by definition of public"
    no
(intrascope)
     |
ancestrally related (i.e., one domain is an ancestor of the other)?
     | \
     |   yes
     |     \
     |       \   public-in-public
     |                      |\
     |                      |  yes -> ??
    no                   no
(cross-domain)  (private-in-private)
     |                      |
   ??                    ??

Why is it useful to understand this breakdown to understand the problem?
Because in many cases it might be *sufficient* to simply know if there is a
boundary and if the two names are on different sides.  In other cases
(either because of the nature of the names or the application) it is
important to more fully understand the relationships in their entirety.
The Mozilla PSL allows a client to answer (only) the very top question.

An analogy that might help is setting up firewall rules for machines on a
campus.  Rules can be set on the border of the campus border or on
individual hosts.  Suppose 90% of the machines on campus require no
inbound-initiated network connectivity.  What would happen if the campus
didn't distinguish between the 90% and the 10%, but rather allowed all
clients to handle their own firewall configurations?  Certainly it could
work, but there are concerns about consistency and complexity.  When you
have one primary rule to weed out the majority of the issues (in this case,
blocking *all* inbound traffic for the 90% of hosts), that simplifies the
problem space.  For finer-grained tuning, the 10% are configured with
policy at their respective hosts.

Suppose we learn from application use case and demand that learning a
boundary is indeed sufficient for some high number of cases.  To me it
would behoove the group to consider that as part of the solution(s).
Additional considerations are the portability and scalability
characteristics of this solution(s), the flexibility of the solution, the
comparison of lookup time with freshness time (i.e., comparing the current
Mozilla PSL with a more dynamic, e.g., DNS-based, approach), and others.

>
>
> Every application I've seen for the PSL asks one of these three questions:
>

Note that these are application-specific questions under the more general
question of domain relationships.

> * Are names A and B under the same authority? (the cookie question)
>

I would think the question here is: is A allowed to set cookies for B (or
vice-versa)?  One way of solving that is asking whether A and B are under
the same authority, but then how do you define authority?  For example,
foo.uk.com resides within the uk.com zone.  The Mozilla PSL tells us that
uk.com is "public" and foo.uk.com is not.  Does that mean they are under
the same authority?  However, the Mozilla PSL (and, in this case, the
decision tree above) tell us that there is a public/private boundary
between foo.com and foo.uk.com, so they are not "positively associated"
(i.e., for policy).

> * Are all the names covered by this wildcard under the same authority?
(the cert question)
>

This is an example of a (good) question that cannot be fully answered by
simply answering the top question in the decision tree.  While a
relationship can be ruled out if the name resides within a first-level
public boundary, more fine-grained control is necessary to understand the
problem at hand.

> * What's the shortest* name under the same authority as this one? (the
DMARC question)
>

It seemed to me that the DMARC question was also about general
relationships between domains, and determining the shortest name under some
authority was more about applying the current PSL to the problem space.

> None of those answers seem to me to make any sort of public/private
distinction.

But all of these can make *use* of a known public boundary, if one exists.
We know that from application (sometimes over-application) of the Mozilla
PSL.

Best regards,
Casey

--20cf303ea6306695db05082393a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi John,<br><br>On Mon, Nov 17, 2014 at 4:5=
0 PM, John R Levine &lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank=
">johnl@taugh.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; That being said, I=
 had proposed that the problem of identifying domain<br>&gt;&gt; relationsh=
ips and boundaries was broken up into several areas, one of which<br>&gt;&g=
t; was &quot;cross-scope&quot; ...<br>&gt;<br>&gt;<br>&gt; Honestly, I saw =
your chart, but I didn&#39;t understand it.<br><br><br>The tree map represe=
nts a breakdown of comparison characteristics for domain names, for the pur=
poses of determining whether the two can be positively associated (i.e., fo=
r some application).=C2=A0 Think of it like a decision tree, where the area=
 of each subdivision in the map represents the likelihood that the branch w=
ill be followed.=C2=A0 The tree looks something like this (note that this i=
s considered a work-in-progress and not a definitive model):<br><br>cross s=
cope?<br>=C2=A0 =C2=A0 =C2=A0|\<br>=C2=A0 =C2=A0 =C2=A0| =C2=A0yes -&gt; &q=
uot;no positive association, by definition of public&quot;<br>=C2=A0 =C2=A0=
 no<br>(intrascope)<br>=C2=A0 =C2=A0 =C2=A0|<br>ancestrally related (i.e., =
one domain is an ancestor of the other)?<br>=C2=A0 =C2=A0 =C2=A0| \<br>=C2=
=A0 =C2=A0 =C2=A0| =C2=A0 yes<br>=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 \<br>=
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 \ =C2=A0 public-in-public<br>=C2=
=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0=C2=A0 =C2=A0 |\<br>=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 | =C2=A0yes -&gt; ??<br>=
=C2=A0 =C2=A0 no =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 no<br>(cross-domain)=C2=A0 (private-in-private)<br>=C2=A0 =C2=A0=C2=
=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |<br>=C2=A0=C2=A0 ?? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ??<br><br></div>Why is it usefu=
l to understand this breakdown to understand the problem?=C2=A0 Because in =
many cases it might be *sufficient* to simply know if there is a boundary a=
nd if the two names are on different sides.=C2=A0 In other cases (either be=
cause of the nature of the names or the application) it is important to mor=
e fully understand the relationships in their entirety.=C2=A0 The Mozilla P=
SL allows a client to answer (only) the very top question.<br><br></div>An =
analogy that might help is setting up firewall rules for machines on a camp=
us.=C2=A0 Rules can be set on the border of the campus border or on individ=
ual hosts.=C2=A0 Suppose 90% of the machines on campus require no inbound-i=
nitiated network connectivity.=C2=A0 What would happen if the campus didn&#=
39;t distinguish between the 90% and the 10%, but rather allowed all client=
s to handle their own firewall configurations?=C2=A0 Certainly it could wor=
k, but there are concerns about consistency and complexity.=C2=A0 When you =
have one primary rule to weed out the majority of the issues (in this case,=
 blocking *all* inbound traffic for the 90% of hosts), that simplifies the =
problem space.=C2=A0 For finer-grained tuning, the 10% are configured with =
policy at their respective hosts.<br><br></div>Suppose we learn from applic=
ation use case and demand that learning a boundary is indeed sufficient for=
 some high number of cases.=C2=A0 To me it would behoove the group to consi=
der that as part of the solution(s).=C2=A0 Additional considerations are th=
e portability and scalability characteristics of this solution(s), the flex=
ibility of the solution, the comparison of lookup time with freshness time =
(i.e., comparing the current Mozilla PSL with a more dynamic, e.g., DNS-bas=
ed, approach), and others.<br><div><div><div><div><br>&gt;<br>&gt;<br>&gt; =
Every application I&#39;ve seen for the PSL asks one of these three questio=
ns:<br>&gt;<br><br></div><div>Note that these are application-specific ques=
tions under the more general question of domain relationships.<br></div><di=
v><br>&gt; * Are names A and B under the same authority? (the cookie questi=
on)<br>&gt;<br><br></div><div>I would think the question here is: is A allo=
wed to set cookies for B (or vice-versa)?=C2=A0 One way of solving that is =
asking whether A and B are under the same authority, but then how do you de=
fine authority?=C2=A0 For example, <a href=3D"http://foo.uk.com">foo.uk.com=
</a> resides within the <a href=3D"http://uk.com">uk.com</a> zone.=C2=A0 Th=
e Mozilla PSL tells us that <a href=3D"http://uk.com">uk.com</a> is &quot;p=
ublic&quot; and <a href=3D"http://foo.uk.com">foo.uk.com</a> is not.=C2=A0 =
Does that mean they are under the same authority?=C2=A0 However, the Mozill=
a PSL (and, in this case, the decision tree above) tell us that there is a =
public/private boundary between <a href=3D"http://foo.com">foo.com</a> and =
<a href=3D"http://foo.uk.com">foo.uk.com</a>, so they are not &quot;positiv=
ely associated&quot; (i.e., for policy).<br><br></div><div>&gt; * Are all t=
he names covered by this wildcard under the same authority? (the cert quest=
ion)<br></div><div>&gt;<br><br></div><div>This is an example of a (good) qu=
estion that cannot be fully answered by simply answering the top question i=
n the decision tree.=C2=A0 While a relationship can be ruled out if the nam=
e resides within a first-level public boundary, more fine-grained control i=
s necessary to understand the problem at hand.<br></div><div><br>&gt; * Wha=
t&#39;s the shortest* name under the same authority as this one? (the DMARC=
 question)<br>&gt;<br><br></div><div>It seemed to me that the DMARC questio=
n was also about general relationships between domains, and determining the=
 shortest name under some authority was more about applying the current PSL=
 to the problem space.<br></div><div><br>&gt; None of those answers seem to=
 me to make any sort of public/private distinction.<br><br></div><div>But a=
ll of these can make *use* of a known public boundary, if one exists.=C2=A0=
 We know that from application (sometimes over-application) of the Mozilla =
PSL.<br></div><div><br>Best regards,<br>Casey</div></div></div></div></div>

--20cf303ea6306695db05082393a8--


From nobody Tue Nov 18 07:45:54 2014
Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6D41A19FD for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 07:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level: 
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHxpPVu1KYWe for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 07:45:50 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2351A19E9 for <dbound@ietf.org>; Tue, 18 Nov 2014 07:45:50 -0800 (PST)
Received: (qmail 45536 invoked from network); 18 Nov 2014 15:45:48 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 18 Nov 2014 15:45:48 -0000
Date: 18 Nov 2014 15:45:26 -0000
Message-ID: <20141118154526.3105.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <546B4C37.3020007@comodo.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/dHs9kLF2W1ZYpwuVGy9V4uVK6_4
Cc: rob.stradling@comodo.com
Subject: Re: [Dbound] multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 15:45:51 -0000

>Could DBOUND specify an "evil bit" so that we can easily recognize dodgy 
>domains ?  ;-)

If you want DNSBLs, you know where to find them.

R's,
John


From nobody Tue Nov 18 08:33:41 2014
Return-Path: <warren@kumari.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3331A1A56 for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 08:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3PwL6ICdb8s for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 08:33:33 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE691A1A88 for <dbound@ietf.org>; Tue, 18 Nov 2014 08:33:33 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id l18so4572048wgh.40 for <dbound@ietf.org>; Tue, 18 Nov 2014 08:33:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bhr3f4h7pzh27WIbUiNvoNiZ9NKsBO9GnSbulx/lMng=; b=HPCAhWEBPUoFWAWjBcIu11V9OAiadjbdhe29xN9k20cidHKEWAvpdZ5vsEvAdRWXj7 EdsxQUL9kfQVMEEIJM1nzSl1Lw5pfbFmf3zXi+0VK8jIzsP/0QT1MPqNEGHctlQhIxmm Fg25gC9E0Mhvye+49uv3f/ZZ2YH4qKxCubmkPPvyoKy/tR9mJKmDjciZhiwU7o6CLe2g tTmw4LabKRr3PJi5UJEGzp2v27swpjORu1QP2Bh7DP7Y9FpyZ3+pQq+GVakQa1tTLWm+ 85Cy8m3SzamgjB5El1tTiQsCnvBuHDioRoBG6cL8Fc7k3E3hCNtGuJ0/BzzPNg9Wx7tm 0yJA==
X-Gm-Message-State: ALoCoQk14C5qV37wwfPRxjo9pXha3Qz1UaBCciOT+H+Vk2Io0ciI2GdHJBoh+GFluak3QvXUyNpp
MIME-Version: 1.0
X-Received: by 10.194.63.229 with SMTP id j5mr49417237wjs.23.1416328412114; Tue, 18 Nov 2014 08:33:32 -0800 (PST)
Received: by 10.194.64.37 with HTTP; Tue, 18 Nov 2014 08:33:32 -0800 (PST)
In-Reply-To: <546B0B8B.6000703@centralnic.com>
References: <546A4636.4050502@KingsMountain.com> <546A50D8.3@gmail.com> <546B0B8B.6000703@centralnic.com>
Date: Tue, 18 Nov 2014 06:33:32 -1000
Message-ID: <CAHw9_iKu+Uv0X-dTg31Myxrqu5jsvnNPSKuiVM=ouY0mwPNHyw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Gavin Brown <gavin.brown@centralnic.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/hXs0LpTbMLmgklb61tZ7E5RYgSQ
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dbound@ietf.org
Subject: Re: [Dbound] commands to get TLD list (was: multiple PSL-equivalents exist..
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 16:33:40 -0000

On Mon, Nov 17, 2014 at 11:04 PM, Gavin Brown
<gavin.brown@centralnic.com> wrote:
> IANA publishes a flat list of TLDs:
>
> https://data.iana.org/TLD/tlds-alpha-by-domain.txt

My God -- it's full of sta^wnames...

W


>
> On 17/11/2014 19:47, Tim Wicinski wrote:
>>
>> Or for us very lazy one-liner types:
>>
>> curl -s http://www.internic.net/domain/root.zone  | awk '$4 == "NS" {
>> print $1 }' | sed 's/\.$//' | sort -u
>>
>>
>>
>> On 11/17/14 11:02 AM, =JeffH wrote:
>>> Casey supplied..
>>>
>>>  > awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u >
>>> tlds.txt
>>>
>>> cool, thx. tho one needs to do this first to get the root.zone file..
>>>
>>> wget http://www.internic.net/domain/root.zone
>>> awk '$4 == "NS" { print $1 }' root.zone | sed 's/\.$//' | sort -u >
>>> tlds.txt
>>>
>>> [see also: https://www.iana.org/domains/root/files ]
>>>
>>>
>>> results:
>>>
>>>  > head -20 tlds.txt
>>>
>>> abogado
>>> ac
>>> academy
>>> accountants
>>> active
>>> actor
>>> ad
>>> ae
>>> aero
>>> af
>>> ag
>>> agency
>>> ai
>>> airforce
>>> al
>>> allfinanz
>>> alsace
>>> am
>>> an
>>> ...
>>>
>>>
>>> _______________________________________________
>>> Dbound mailing list
>>> Dbound@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dbound
>>
>>
>
> --
> Gavin Brown
> Chief Technology Officer
> CentralNic Group plc (LSE:CNIC)
> Innovative, Reliable and Flexible Registry Services
> for ccTLD, gTLD and private domain name registries
> https://www.centralnic.com/
>
> CentralNic Group plc is a company registered in England and Wales with
> company number 8576358. Registered Offices: 35-39 Moorgate, London,
> EC2R 6AR.
>
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Tue Nov 18 09:31:58 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E661A1B64 for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 09:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD3dW1Twyow9 for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 09:31:53 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A268E1A1A95 for <dbound@ietf.org>; Tue, 18 Nov 2014 09:31:53 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id hl2so4590926igb.11 for <dbound@ietf.org>; Tue, 18 Nov 2014 09:31:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AzuGjGWRlqKmAHQngPpdhhzoRTGbHdW9HZCpj/aAT4Y=; b=PyEgPVscoGjrrcJH9wBoNJGoDaBIvZ4a0ct/K9zuT2zGPkhMNqa704HZkz7E2v3NQF jxxrwgO4djLk3yzS32PzdhGP07NzTOELX6fVx/DPgVFfqyn3bu/YP0p6USu+0ftEhEun IlBeOKoN0AAZ118J2dnqCMbaq/BAuKPHD3xy4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AzuGjGWRlqKmAHQngPpdhhzoRTGbHdW9HZCpj/aAT4Y=; b=fwuQl+2IZndsx9eErY1D4TZS3SJYX7mf1Ohes9qbHaLfjzmzfDQIaJKVL0W5vn7KZ7 TGtZTMkPG+6mEA36xyn77j0QFwUSf6d3Lc7uMZPXmdsBVAZj1MwIkBOIW4qwCIcEf6et idIoctUZwIxLrvEe2/yd6otbK2dQrYKi7dk/z3kurqe7sBc5zSaDgPwRyQd+xYGga6Ab VJ6ZTRo7JGBehXRlBNWWKCRFGt1vxQpbyn+1cFWhkek7KC9YYribtIkd8QA//vnpyVVQ 9xR96gbH7QNW4W8QP99waM82AjjxjBwJaRYkX7112v/q7JnxtpaeUJSFMEwcFijwrJk/ DrNw==
X-Gm-Message-State: ALoCoQnqpQ8Y5uvWiS+ZbR36HweMHl5BHfXNpI6+FoOzF+Vbv48a3gfAYzUR5qpSg7XJ1h7uTfLs
MIME-Version: 1.0
X-Received: by 10.50.142.33 with SMTP id rt1mr4981313igb.12.1416331912845; Tue, 18 Nov 2014 09:31:52 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 18 Nov 2014 09:31:52 -0800 (PST)
In-Reply-To: <CABuGu1p7sshNG2KOe0GDFGAz3S+OeJB-G3bm_e1jiGPUsu1k=g@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com> <alpine.OSX.2.11.1411171643500.18601@ary.lan> <CAEKtLiSN9VNEF+4rgECsfe=rkXdD-AggTMGzNtX9a4teKRjWRA@mail.gmail.com> <CABuGu1p7sshNG2KOe0GDFGAz3S+OeJB-G3bm_e1jiGPUsu1k=g@mail.gmail.com>
Date: Tue, 18 Nov 2014 12:31:52 -0500
Message-ID: <CAEKtLiRMNuxAA--Wbv52ce9yAicsbKXPR-DTQ8=1vLU5gkG7fQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Kurt Andersen <kurta@drkurt.com>
Content-Type: multipart/alternative; boundary=001a1130d17a8cbf740508257865
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/eARf2DZrhnnUJP2c4wKxisqEy_g
Cc: John R Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 17:31:55 -0000

--001a1130d17a8cbf740508257865
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 18, 2014 at 12:05 PM, Kurt Andersen <kurta@drkurt.com> wrote:

>
> On Tue, Nov 18, 2014 at 7:16 AM, Casey Deccio <casey@deccio.net> wrote:
>>
>> > * What's the shortest* name under the same authority as this one? (the
>> DMARC question)
>>
>> It seemed to me that the DMARC question was also about general
>> relationships between domains, and determining the shortest name under some
>> authority was more about applying the current PSL to the problem space.
>>
>
> No, the PSL was used as a workable short term strategy to accomplish
> something much like your campus firewall approach: look for a policy on the
> actual from domain and if not found, fall back to the "campus" policy (the
> "organizational domain" in DMARC terms). The "shortest name" was adopted
> from an ancestral descent model.
>

I think that is what I was trying to say: lacking a full-blown mechanism
for specifying relationships between arbitrary domains, the PSL was applied
to the problem, identifying the highest ancestor below the public boundary
as the organizational domain.  Does that sound more accurate?

I am not suggesting that using the PSL was the optimal approach, only that
it seemed to me that the terminology used reflected the use of the PSL as
the interim approach.

Best regards,
Casey

--001a1130d17a8cbf740508257865
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 18, 2014 at 12:05 PM, Kurt Andersen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:kurta@drkurt.com" target=3D"_blank">kurta@dr=
kurt.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Tue, Nov 18=
, 2014 at 7:16 AM, Casey Deccio <span dir=3D"ltr">&lt;<a href=3D"mailto:cas=
ey@deccio.net" target=3D"_blank">casey@deccio.net</a>&gt;</span> wrote:</sp=
an> <span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
><div><div><div><span><div>&gt; * What&#39;s the shortest* name under the s=
ame authority as this one? (the DMARC question)<br><br></div></span><div>It=
 seemed to me that the DMARC question was also about general relationships =
between domains, and determining the shortest name under some authority was=
 more about applying the current PSL to the problem space.<br></div><span><=
div></div></span></div></div></div></div></blockquote></span></div><br></di=
v><div class=3D"gmail_extra">No, the PSL was used as a workable short term =
strategy to accomplish something much like your campus firewall approach: l=
ook for a policy on the actual from domain and if not found, fall back to t=
he &quot;campus&quot; policy (the &quot;organizational domain&quot; in DMAR=
C terms). The &quot;shortest name&quot; was adopted from an ancestral desce=
nt model.</div></div></blockquote><div><br></div><div>I think that is what =
I was trying to say: lacking a full-blown mechanism for specifying relation=
ships between arbitrary domains, the PSL was applied to the problem, identi=
fying the highest ancestor below the public boundary as the organizational =
domain.=C2=A0 Does that sound more accurate?<br><br>I am not suggesting tha=
t using the PSL was the optimal approach, only that it seemed to me that th=
e terminology used reflected the use of the PSL as the interim approach.<br=
></div><div><br></div><div>Best regards,<br></div><div>Casey<br></div></div=
></div></div>

--001a1130d17a8cbf740508257865--


From nobody Tue Nov 18 12:37:12 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA11A1AB3 for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 09:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbEEoCHdj2ws for <dbound@ietfa.amsl.com>; Tue, 18 Nov 2014 09:05:12 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1AE1A1AF0 for <dbound@ietf.org>; Tue, 18 Nov 2014 09:05:03 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id r20so6955998wiv.14 for <dbound@ietf.org>; Tue, 18 Nov 2014 09:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c+JYbdt5gd5cyDFrWN/3aiXwqOTmS4W9hPbwBToiWyM=; b=JlHKTL9qaFbXmzwvdQXvx3pGiUAWtcieKQx65e84LIq7lCJZktocEDKDdJc1DpJ8TW 3R7zzZj6Cvso0DC2n7Akd6BIuBtLnECIwy27UwJ8xFyQcLIHXl1eGHEMGShTbzOlIxdg ehd/d/Eb6kFQ63qB8rnJObOcDNCWQWO3hAaYM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c+JYbdt5gd5cyDFrWN/3aiXwqOTmS4W9hPbwBToiWyM=; b=UinPdpNSKjW5DMwI7tazSYxzUHq3Cm/xOty1uAIttUVymb8oDBRhMOkUukxwZPSRV3 Bw5FOGxzQLf3svUgYEOwumfpwcMi94siC17PHhNCAkItjVSDM5H1RWEiOiaaMrciBoLE ljuBVUbV2s3f0mHxFci6/edxggWxazjoi0gaS/OApvdzZ6HAhifMz1MTvZZCoQpXilZW 1y1kw6WThRemmyjMy2Ug7t1MjUIXU5o5NWbWg2Zi/vJvQhqVaJ62A/6KhzrXmkmdxoDm 400ej9RNJGpikKecg0zbpTEk//WD114ONboALxf6OsfnUhyzNnccUQbjImFYT9T2iV8u KIgw==
X-Gm-Message-State: ALoCoQluBPqXrnsKFWEDTDKWpV6fPL91+Mk2hllp9c//X8/br4bkmxlhwIj6kk6siRROE2vLIuRI
MIME-Version: 1.0
X-Received: by 10.194.109.226 with SMTP id hv2mr49220592wjb.45.1416330302576;  Tue, 18 Nov 2014 09:05:02 -0800 (PST)
Received: by 10.194.188.115 with HTTP; Tue, 18 Nov 2014 09:05:02 -0800 (PST)
In-Reply-To: <CAEKtLiSN9VNEF+4rgECsfe=rkXdD-AggTMGzNtX9a4teKRjWRA@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com> <alpine.OSX.2.11.1411171643500.18601@ary.lan> <CAEKtLiSN9VNEF+4rgECsfe=rkXdD-AggTMGzNtX9a4teKRjWRA@mail.gmail.com>
Date: Tue, 18 Nov 2014 09:05:02 -0800
Message-ID: <CABuGu1p7sshNG2KOe0GDFGAz3S+OeJB-G3bm_e1jiGPUsu1k=g@mail.gmail.com>
From: Kurt Andersen <kurta@drkurt.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: multipart/alternative; boundary=089e0102fc4c91f43c0508251895
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/GT54O4tPrv62cTHSUL9ROieD1KE
X-Mailman-Approved-At: Tue, 18 Nov 2014 12:37:09 -0800
Cc: John R Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 17:05:17 -0000

--089e0102fc4c91f43c0508251895
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 18, 2014 at 7:16 AM, Casey Deccio <casey@deccio.net> wrote:

> An analogy that might help is setting up firewall rules for machines on a
> campus.  Rules can be set on the border of the campus border or on
> individual hosts.  Suppose 90% of the machines on campus require no
> inbound-initiated network connectivity.  What would happen if the campus
> didn't distinguish between the 90% and the 10%, but rather allowed all
> clients to handle their own firewall configurations?  Certainly it could
> work, but there are concerns about consistency and complexity.  When you
> have one primary rule to weed out the majority of the issues (in this case,
> blocking *all* inbound traffic for the 90% of hosts), that simplifies the
> problem space.  For finer-grained tuning, the 10% are configured with
> policy at their respective hosts.
>

<elided>


> > * What's the shortest* name under the same authority as this one? (the
> DMARC question)
>
> It seemed to me that the DMARC question was also about general
> relationships between domains, and determining the shortest name under some
> authority was more about applying the current PSL to the problem space.
>

No, the PSL was used as a workable short term strategy to accomplish
something much like your campus firewall approach: look for a policy on the
actual from domain and if not found, fall back to the "campus" policy (the
"organizational domain" in DMARC terms). The "shortest name" was adopted
from an ancestral descent model.  Except for the lookup overhead, SOPA
offered something closer to what DMARC would really like to have available.

--Kurt Andersen

--089e0102fc4c91f43c0508251895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Nov 18, 2014 at 7:16 AM, Casey Deccio <span dir=3D"ltr">&lt;<a href=
=3D"mailto:casey@deccio.net" target=3D"_blank">casey@deccio.net</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>An ana=
logy that might help is setting up firewall rules for machines on a campus.=
=C2=A0 Rules can be set on the border of the campus border or on individual=
 hosts.=C2=A0 Suppose 90% of the machines on campus require no inbound-init=
iated network connectivity.=C2=A0 What would happen if the campus didn&#39;=
t distinguish between the 90% and the 10%, but rather allowed all clients t=
o handle their own firewall configurations?=C2=A0 Certainly it could work, =
but there are concerns about consistency and complexity.=C2=A0 When you hav=
e one primary rule to weed out the majority of the issues (in this case, bl=
ocking *all* inbound traffic for the 90% of hosts), that simplifies the pro=
blem space.=C2=A0 For finer-grained tuning, the 10% are configured with pol=
icy at their respective hosts.</div></blockquote><div>=C2=A0<br>&lt;elided&=
gt;<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div><div><div><div><span class=3D""><div>&gt; * What&#39;s the shorte=
st* name under the same authority as this one? (the DMARC question)<br><br>=
</div></span><div>It seemed to me that the DMARC question was also about ge=
neral relationships between domains, and determining the shortest name unde=
r some authority was more about applying the current PSL to the problem spa=
ce.<br></div><span class=3D""><div></div></span></div></div></div></div></b=
lockquote></div><br></div><div class=3D"gmail_extra">No, the PSL was used a=
s a workable short term strategy to accomplish something much like your cam=
pus firewall approach: look for a policy on the actual from domain and if n=
ot found, fall back to the &quot;campus&quot; policy (the &quot;organizatio=
nal domain&quot; in DMARC terms). The &quot;shortest name&quot; was adopted=
 from an ancestral descent model.=C2=A0 Except for the lookup overhead, SOP=
A offered something closer to what DMARC would really like to have availabl=
e.<br><br></div><div class=3D"gmail_extra">--Kurt Andersen<br></div></div>

--089e0102fc4c91f43c0508251895--


From nobody Mon Nov 24 10:29:40 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97F1A0673 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 10:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYKAXnUIh3oj for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 10:29:28 -0800 (PST)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3251A6FED for <dbound@ietf.org>; Mon, 24 Nov 2014 10:29:28 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id l15so6770755wiw.16 for <dbound@ietf.org>; Mon, 24 Nov 2014 10:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=kAHowZWitrK7SXS7CU2cMYD8ogWztrNY62fW/XqnaTA=; b=cHnon/H+bsOqDzYnoDI+fI+L0G6RhLQhNQgKTQ+/ki/Cm8++GRdYSFNvKncFb7JAQ5 TqEFBdRnZhVfAxBbVJ+pcD8UKzO8oftqA2Rs6eeu5sRSA4ZayH20Ya7kesh4sK+qLuIW X6xmN9kAflv7Onw6x/UqdTDAEvBuxVPwG3jczFM4U7EPLLgPdNcFoSw7qVejdBqd/1c2 GIF1pFiyCnAjWGOpWNi9DjE9FtL60/CWNcRMVjewwhwteSyHf9JE5XQbbFok/liJwjtW i5QrqE5GKFsREqqVvN7KGpHgqHiibjhkBlTLe4+ls2R8EKyOaSNyORdCD1UcZCL2Q6ai KQ5g==
MIME-Version: 1.0
X-Received: by 10.194.3.2 with SMTP id 2mr36747040wjy.89.1416853767276; Mon, 24 Nov 2014 10:29:27 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 10:29:27 -0800 (PST)
Date: Mon, 24 Nov 2014 10:29:27 -0800
Message-ID: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: dbound@ietf.org
Content-Type: multipart/alternative; boundary=047d7b343c187f4df505089ef9e6
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/NL5TkdBvhQQPJ2E2G_HMYILTDMs
Subject: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 18:29:33 -0000

--047d7b343c187f4df505089ef9e6
Content-Type: text/plain; charset=UTF-8

Hi all,

I put this together based on the dbound draft Jeff made available via
github during the quasi-BoF in Honolulu.  A bit of it is copied from there,
some of it is from what I overheard in that meeting, and some of it I just
made up while on my way to work.

Edit away.

-MSK

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two Domain Name System (DNS) names are related.  A
popular example is the need to determine whether example.com and
foo.example.com are related; though to humans the answer to this may be
obvious, it is difficult to establish this programatically.

The particular issue is that there is structure imposed by users and by the
domain name registration system that is independent of the architecture and
protocol upon which the DNS is built.

In the realm of email, there is a desire to map an arbitrary domain name to
the registered domain name somewhere in the tree above it, in order to
identify a deterministic location where some sort of statement of policy
regarding that domain name can be found.  With respect to the web, there is
a similar practice of identifying domains as related as long as they share
a common ancestor.  However, there is an additional need for the capability
to declare relationships between arbitrary names.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617) and
Sender Policy Framework (SPF; RFC7008), and current work such as DMARC
(draft-kucherawy-dmarc-base), would certainly benefit from having this
capability.

Currently, the only solution in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is maintained
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.  When this list is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, and equivalence
problems require independent solutions, in which case the working group
will follow that path.  The solutions may or may not involve changes to the
DNS, such as creation of new resource record types; in any case, all such
changes will be incremental only.

This working group will not seek to amend the consumer protocols themselves
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
need to be done as individual or independent submissions, or in another
working group.

Milestones:
TBD

Co-chairs:
TBD

--047d7b343c187f4df505089ef9e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all,<br><br>I put this together based on the dboun=
d draft Jeff made available via github during the quasi-BoF in Honolulu.=C2=
=A0 A bit of it is copied from there, some of it is from what I overheard i=
n that meeting, and some of it I just made up while on my way to work.<br><=
br>Edit away.<br><br></div>-MSK<br><br>dbound charter<br><br>Various Intern=
et protocols and applications require some mechanism for determining whethe=
r two Domain Name System (DNS) names are related.=C2=A0 A popular example i=
s the need to determine whether <a href=3D"http://example.com">example.com<=
/a> and <a href=3D"http://foo.example.com">foo.example.com</a> are related;=
 though to humans the answer to this may be obvious, it is difficult to est=
ablish this programatically.<br><br>The particular issue is that there is s=
tructure imposed by users and by the domain name registration system that i=
s independent of the architecture and protocol upon which the DNS is built.=
<br><br>In the realm of email, there is a desire to map an arbitrary domain=
 name to the registered domain name somewhere in the tree above it, in orde=
r to identify a deterministic location where some sort of statement of poli=
cy regarding that domain name can be found.=C2=A0 With respect to the web, =
there is a similar practice of identifying domains as related as long as th=
ey share a common ancestor.=C2=A0 However, there is an additional need for =
the capability to declare relationships between arbitrary names.<br><br>Pre=
vious work such as Author Domain Signing Practices (ADSP; RFC5617) and Send=
er Policy Framework (SPF; RFC7008), and current work such as DMARC (draft-k=
ucherawy-dmarc-base), would certainly benefit from having this capability.<=
br><br>Currently, the only solution in existence is maintained by a web bro=
wser producer, known as the Public Suffix List.=C2=A0 This list, which is m=
aintained by volunteers on a best-effort basis, contains a list of points i=
n the DNS tree at which registrations take place.=C2=A0 When this list is i=
naccurate, it exposes a deviation with reality that degrades service to som=
e and can be exploited by others.<br><br>The DBOUND working group will deve=
lop one or more solutions to this family of problems.=C2=A0 If possible, a =
unified solution will be developed.=C2=A0 However, the working group may di=
scover that the email, web, and equivalence problems require independent so=
lutions, in which case the working group will follow that path.=C2=A0 The s=
olutions may or may not involve changes to the DNS, such as creation of new=
 resource record types; in any case, all such changes will be incremental o=
nly.<br><br>This working group will not seek to amend the consumer protocol=
s themselves (i.e., any web or mail standards) without rechartering, and on=
ly after completion of the base work.=C2=A0 Any such work undertaken in par=
allel will need to be done as individual or independent submissions, or in =
another working group.<br><br>Milestones:<br>TBD<br><br>Co-chairs:<br>TBD<b=
r></div>

--047d7b343c187f4df505089ef9e6--


From nobody Mon Nov 24 12:14:39 2014
Return-Path: <sklist@kitterman.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5017A1A8AB6 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghO1jk43D5ar for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:14:34 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696321A8A8C for <dbound@ietf.org>; Mon, 24 Nov 2014 12:14:34 -0800 (PST)
Received: from [10.188.100.102] (166.sub-70-208-135.myvzw.com [70.208.135.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C6B76C402BA; Mon, 24 Nov 2014 14:14:32 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1416860073; bh=bt6JJS+EpI00+HWI6Mnf6hwvmq9kNusSPi+kqz0UJSk=; h=In-Reply-To:References:Subject:From:Date:To:From; b=hvs+t/9XMrdf2f6WHNaPPukYU7gDadjFGi62AGocWdUVMrZNrgXgZcMvQGh8AGOuJ H7uUbaNmQXd5jNk+cIzxpwr8ABVk8rDiTJ6PCpJgJwCDzIFBDaZr/QPBY4zc7XHUxF NNw7ObhtXmDkX/2GUgvr8ML98Uo28oZotoqqbtSo=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Scott Kitterman <sklist@kitterman.com>
Date: Mon, 24 Nov 2014 15:11:37 -0500
To: dbound@ietf.org
Message-ID: <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/aob-xGI4wT53VPZ98OZsGWWqs3U
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 20:14:36 -0000

On November 24, 2014 1:29:27 PM EST, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>Hi all,
>
>I put this together based on the dbound draft Jeff made available via
>github during the quasi-BoF in Honolulu.  A bit of it is copied from
>there,
>some of it is from what I overheard in that meeting, and some of it I
>just
>made up while on my way to work.
>
>Edit away.
>
>-MSK
>
>dbound charter
>
>Various Internet protocols and applications require some mechanism for
>determining whether two Domain Name System (DNS) names are related.  A
>popular example is the need to determine whether example.com and
>foo.example.com are related; though to humans the answer to this may be
>obvious, it is difficult to establish this programatically.
>
>The particular issue is that there is structure imposed by users and by
>the
>domain name registration system that is independent of the architecture
>and
>protocol upon which the DNS is built.
>
>In the realm of email, there is a desire to map an arbitrary domain
>name to
>the registered domain name somewhere in the tree above it, in order to
>identify a deterministic location where some sort of statement of
>policy
>regarding that domain name can be found.  With respect to the web,
>there is
>a similar practice of identifying domains as related as long as they
>share
>a common ancestor.  However, there is an additional need for the
>capability
>to declare relationships between arbitrary names.
>
>Previous work such as Author Domain Signing Practices (ADSP; RFC5617)
>and
>Sender Policy Framework (SPF; RFC7008), and current work such as DMARC
>(draft-kucherawy-dmarc-base), would certainly benefit from having this
>capability.
>
>Currently, the only solution in existence is maintained by a web
>browser
>producer, known as the Public Suffix List.  This list, which is
>maintained
>by volunteers on a best-effort basis, contains a list of points in the
>DNS
>tree at which registrations take place.  When this list is inaccurate,
>it
>exposes a deviation with reality that degrades service to some and can
>be
>exploited by others.
>
>The DBOUND working group will develop one or more solutions to this
>family
>of problems.  If possible, a unified solution will be developed. 
>However,
>the working group may discover that the email, web, and equivalence
>problems require independent solutions, in which case the working group
>will follow that path.  The solutions may or may not involve changes to
>the
>DNS, such as creation of new resource record types; in any case, all
>such
>changes will be incremental only.
>
>This working group will not seek to amend the consumer protocols
>themselves
>(i.e., any web or mail standards) without rechartering, and only after
>completion of the base work.  Any such work undertaken in parallel will
>need to be done as individual or independent submissions, or in another
>working group.

I'd delete the SPF reference. SPF certainly could have used this a decade ago, but now, not so much. There was an attempt at including walking up the DNS tree to an admin boundary in some early drafts, but it was abandoned long ago. 

Scott K


From nobody Mon Nov 24 12:31:54 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DB1A8A8B for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUYhYHfwg5wJ for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:31:51 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFE31A1AC6 for <dbound@ietf.org>; Mon, 24 Nov 2014 12:31:51 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ex7so7170693wid.12 for <dbound@ietf.org>; Mon, 24 Nov 2014 12:31:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HYRyZSR8vLjav7Etv/O8BoPdDmxj6DJJqFyFbAHXq18=; b=YOGe4iWTe6MagEIMbvnJW2Ah4OgJwskgbPNjwmsWsXQFt+SpDygghIMgYcjwgu2Fi4 Ix6+YHnaZeHlNe4eltwCg8KIM1ew0m3B7MulNl+CunnxLK+3MOeF0ASGtLob1Gi2Yf3H Ylk8wmeuPtFftHS+LsLD4SU/wiAO3zQ6rh0KBPokbcZKqtqDl22G0v+hR9x9f6pB+DFS 0XHjO18j0b1h5jegRGkgLEFrFEXXNQ4QnkU7P5AXhXjeleZ71uiUPZKQvJgkipzQQOPX BDaiVu89WAbe7y1QMl5wf7E4bGkvnsWDYxf28l3tk8ccw3p3Pm/0yD50GMjHMnn4QwFF Ea6Q==
MIME-Version: 1.0
X-Received: by 10.194.62.76 with SMTP id w12mr19202646wjr.5.1416861109829; Mon, 24 Nov 2014 12:31:49 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 12:31:49 -0800 (PST)
In-Reply-To: <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com>
Date: Mon, 24 Nov 2014 12:31:49 -0800
Message-ID: <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Content-Type: multipart/alternative; boundary=047d7ba977a425c5940508a0af71
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/9Q3Sp11BWShr4agtvaS1MTQd7zQ
Cc: dbound@ietf.org
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 20:31:53 -0000

--047d7ba977a425c5940508a0af71
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <sklist@kitterman.com>
wrote:

> I'd delete the SPF reference. SPF certainly could have used this a decade
> ago, but now, not so much. There was an attempt at including walking up the
> DNS tree to an admin boundary in some early drafts, but it was abandoned
> long ago.
>

Speaking completely hypothetically, could SPF not benefit from this today
if it became available?

--047d7ba977a425c5940508a0af71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <span di=
r=3D"ltr">&lt;<a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">skl=
ist@kitterman.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;d delete the SPF=
 reference. SPF certainly could have used this a decade ago, but now, not s=
o much. There was an attempt at including walking up the DNS tree to an adm=
in boundary in some early drafts, but it was abandoned long ago.<br></block=
quote><div><br></div><div>Speaking completely hypothetically, could SPF not=
 benefit from this today if it became available? <br></div></div></div></di=
v>

--047d7ba977a425c5940508a0af71--


From nobody Mon Nov 24 12:36:32 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D511A882C for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TP1Wrv5jGHa for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 12:36:30 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9751A8F49 for <dbound@ietf.org>; Mon, 24 Nov 2014 12:36:29 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id r20so6999294wiv.6 for <dbound@ietf.org>; Mon, 24 Nov 2014 12:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i9ixPPfgyoAOpJ9NPZgju8ZlRFAnPJvu/HlYAy0VYAY=; b=bopdR9DyXqHx38ppnenJHx4dQumBimZBSCfkRhFZYwl6/DFSGFmBr5/yKzCL4vNPyl o3VHIsPoqgOhOW1kPMyZ6dv1G632nc/aNz6m+cT49MYobMeO6YZii8d5mEfsjIHOTwsM 9KmXXpmw2ASaIkW8KnO0IQv4qlUX34i7wh8Yk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i9ixPPfgyoAOpJ9NPZgju8ZlRFAnPJvu/HlYAy0VYAY=; b=IDuVYXvmVjHv1kGnYtte7UIHg0gBC0u4jV49U+06ssVx+dPVgQ8faHQGQa15sLDO82 JLPzWXAq4l6yvIaRYxd/ZvlBgpbfJ3d8ETw09qdmQ4NtzLwNM1zA4BbNQQd4cHcYiIoE wupGBt7Xv+RMNk2i+1ombmsBl7v8gvBqNk+AZEy31sFO1r5Tm0ZDIzlKqsJo45KQl9rM 4lqm6JxPzezAldsGZMoi5ELu4uMNoVTAJdY94BVS3jB68ApzssTwOW3VNRdBOk3DSf/d 3suLnIUaUnf3JsoA2CkUMA7fC2xSD5exxeygsjMDG1AopN877RXt7zu9+Dt/o4EuC9qz C6JQ==
X-Gm-Message-State: ALoCoQks1uPVW0h6QA2rouzDPuyiQLLORv75OP5K3s1VD2ZBi7ccc6gJimlMQ8Zz9Za+KLoUzQvP
MIME-Version: 1.0
X-Received: by 10.180.84.198 with SMTP id b6mr25278931wiz.41.1416861388706; Mon, 24 Nov 2014 12:36:28 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Mon, 24 Nov 2014 12:36:28 -0800 (PST)
In-Reply-To: <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com> <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com>
Date: Mon, 24 Nov 2014 12:36:28 -0800
X-Google-Sender-Auth: 0RGhQJPM6M_EKCefVlPzmffRncI
Message-ID: <CABuGu1oDBEOtCFFUjeBYCmnUfXwcxOzDVTEsTV9rU9+t0PRZyw@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0418264ac52ccb0508a0bf33
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/MJ-tu7SmjYKunD5uXfpv9OvEgB0
Cc: Scott Kitterman <sklist@kitterman.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 20:36:31 -0000

--f46d0418264ac52ccb0508a0bf33
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 12:31 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <sklist@kitterman.com>
> wrote:
>
>> I'd delete the SPF reference. SPF certainly could have used this a decade
>> ago, but now, not so much. There was an attempt at including walking up the
>> DNS tree to an admin boundary in some early drafts, but it was abandoned
>> long ago.
>>
>
> Speaking completely hypothetically, could SPF not benefit from this today
> if it became available?
>

Only if enough people were willing to bear the pain of re-opening the spec
(SPFbis/bis?) yet again to consider doing something with it.

--Kurt

--f46d0418264ac52ccb0508a0bf33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 12:31 PM, Murray S. Kucherawy <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">=
superuser@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D"">On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <span dir=
=3D"ltr">&lt;<a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">skli=
st@kitterman.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I&#39;d delete the SPF reference. SPF certainly could have used this a dec=
ade ago, but now, not so much. There was an attempt at including walking up=
 the DNS tree to an admin boundary in some early drafts, but it was abandon=
ed long ago.<br></blockquote><div><br></div></span><div>Speaking completely=
 hypothetically, could SPF not benefit from this today if it became availab=
le? <br></div></div></div></div></blockquote><div><br></div><div>Only if en=
ough people were willing to bear the pain of re-opening the spec (SPFbis/bi=
s?) yet again to consider doing something with it.<br><br></div><div>--Kurt=
 <br></div></div><br></div></div>

--f46d0418264ac52ccb0508a0bf33--


From nobody Mon Nov 24 13:09:15 2014
Return-Path: <sklist@kitterman.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318C51A9132 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 13:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDOuhHUHXrBF for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 13:09:02 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361B81A912D for <dbound@ietf.org>; Mon, 24 Nov 2014 13:09:02 -0800 (PST)
Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4E6D9C40031 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:09:01 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1416863341; bh=38g1zD9xIvSszAqxksRxGnHfAEaZa/Usy1fMHPjaiZ8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qM9vhaRxuEuUmpwiU6oOyy9Tx24c67wBQ7bmDqf2giepzgEePjKZZ33I9fscONyFM N8fIzbL9rW8w/+5O/E4A/iGDz4NMO03i+Xwlq5t36epSC69iI+yTaAKTeRiG9mhgNc 5RvlVJ+HMJD2e59aCrH6HekhM8QR2G1O3bV5pgtQ=
From: Scott Kitterman <sklist@kitterman.com>
To: dbound@ietf.org
Date: Mon, 24 Nov 2014 16:09:49 -0500
Message-ID: <18167801.pVObHAHZSv@kitterman-optiplex-9020m>
User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com> <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/v1iybaredC_KV8oMhoTr4X_hShw
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 21:09:09 -0000

On Monday, November 24, 2014 12:31:49 PM Murray S. Kucherawy wrote:
> On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <sklist@kitterman.com>
> 
> wrote:
> > I'd delete the SPF reference. SPF certainly could have used this a decade
> > ago, but now, not so much. There was an attempt at including walking up
> > the
> > DNS tree to an admin boundary in some early drafts, but it was abandoned
> > long ago.
> 
> Speaking completely hypothetically, could SPF not benefit from this today
> if it became available?

Not in a backwards compatible way.  

If there were to be a future non-backward compatible update to SPF, then yes, 
it would be useful, but I consider that unlikely anytime soon.  It's certainly 
not a significant rationale for doing the dbound work (which I think is good 
work to do for other reasons).

Scott K


From nobody Mon Nov 24 14:10:48 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDBB1ACCEC for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqZL5kfGFqXj for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:10:39 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A44E1ACCF0 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:10:18 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 24 Nov 2014 14:10:14 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 24 Nov 2014 14:10:14 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Sketch charter
Thread-Index: AQHQCBSr7gqlyJktkEiFvvJMtfoiO5xwiPOA
Date: Mon, 24 Nov 2014 22:10:13 +0000
Message-ID: <D099140A.7283%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
In-Reply-To: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499693809_32380106"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/boF6zN8Ythx5j-vHq7r0OzKnRv8
Cc: "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:10:45 -0000

--B_3499693809_32380106
Content-type: multipart/alternative;
	boundary="B_3499693809_32398051"


--B_3499693809_32398051
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I have two nits that I=B9ll raise because these details have been what caused
me (an DNS=B9r) much pain regarding DBOUND.

On 11/24/14, 13:29, "Murray S. Kucherawy" <superuser@gmail.com
<mailto:superuser@gmail.com> > wrote:

>=20
> Various Internet protocols and applications require some mechanism for
> determining whether two Domain Name System (DNS) names are related.  A po=
pular
> example is the need to determine whether example.com <http://example.com>=
  and
> foo.example.com <http://foo.example.com>  are related; though to humans t=
he
> answer to this may be obvious, it is difficult to establish this
> programatically.

I would change this to : require some mechanism for determining whether two
identifiers (based on Domain Name System names) are related.

This is a pain-in-the-neck, pedantic comment but unless we can get folks to
think =B3identifiers=B2 and not =B3domain names=B2 we will continue to get idiots
like myself wondering if you just want the zone cuts.  (You don=B9t.)

>=20
> The particular issue is that there is structure imposed by users and by t=
he
> domain name registration system that is independent of the architecture a=
nd
> protocol upon which the DNS is built.

That is right.  But the wording just doesn=B9t seen to get to the bottom of
it.  Perhaps:

Given two identifiers that happen to correspond to DNS domain names, the
temptation has been to seek a solution that emphasizes the nature and desig=
n
of the DNS protocol.  This needs to be resisted; instead a solution Is
needed that emphasizes the needs of the applications using the identifiers,
not merely what the DNS can offer.  An example of failing to do this
inappropriate reliance on the Public Suffix List.  The PSL is (take the
definition from below & mention that the PSL means =B3yet another registry=B2
and all the inherent pratfalls (yes, pratfalls) that come with running a
registry, especially one that is a =B3third party=B2 to the elements involved.

> =8A=20

The definition below:

> Currently, the only solution in existence is maintained by a web browser
> producer, known as the Public Suffix List.  This list, which is maintaine=
d by
> volunteers on a best-effort basis, contains a list of points in the DNS t=
ree
> at which registrations take place.  When this list is inaccurate, it expo=
ses a
> deviation with reality that degrades service to some and can be exploited=
 by
> others.



--B_3499693809_32398051
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><div><font face=3D"Calibri,sans-=
serif"><span style=3D"font-size: 18px;">I have two nits that I&#8217;ll raise =
because these details have been what caused me (an DNS&#8217;r) much pain re=
garding DBOUND.</span></font></div><div style=3D"color: rgb(0, 0, 0); font-fam=
ily: Calibri, sans-serif; font-size: 14px;"><span style=3D"font-size: 18px;"><=
br></span></div><span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); =
font-family: Calibri, sans-serif; font-size: 14px;"><div><div><span style=3D"f=
ont-size: 18px;">On 11/24/14, 13:29, "Murray S. Kucherawy" &lt;</span><a hre=
f=3D"mailto:superuser@gmail.com"><span style=3D"font-size: 18px;">superuser@gmai=
l.com</span></a><span style=3D"font-size: 18px;">&gt; wrote:</span></div></div=
><div><span style=3D"font-size: 18px;"><br></span></div><blockquote id=3D"MAC_OU=
TLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4df 5 solid; PADDING:0=
 0 0 5; MARGIN:0 0 0 5;"><div><span style=3D"font-size: 18px;"><meta http-equi=
v=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"></span><div><div dir=3D"lt=
r"><div><span style=3D"font-size: 18px;"><br></span></div><div><span style=3D"fo=
nt-size: 18px;">Various Internet protocols and applications require some mec=
hanism for determining whether two Domain Name System (DNS) names are relate=
d.&nbsp; A popular example is the need to determine whether
</span><a href=3D"http://example.com"><span style=3D"font-size: 18px;">example.=
com</span></a><span style=3D"font-size: 18px;"> and </span><a href=3D"http://foo=
.example.com"><span style=3D"font-size: 18px;">
foo.example.com</span></a><span style=3D"font-size: 18px;"> are related; thou=
gh to humans the answer to this may be obvious, it is difficult to establish=
 this programatically.</span></div></div></div></div></blockquote></span><di=
v style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 1=
4px;"><span style=3D"font-size: 18px;"><br></span></div><div style=3D"color: rgb=
(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;"><span style=3D"=
font-size: 18px;">I would change this to : require some mechanism for determ=
ining whether two identifiers (based on Domain Name System names) are relate=
d.</span></div><div style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-s=
erif; font-size: 14px;"><span style=3D"font-size: 18px;"><br></span></div><div=
 style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14=
px;"><span style=3D"font-size: 18px;">This is a pain-in-the-neck, pedantic com=
ment but unless we can get folks to think &#8220;identifiers&#8221; and not =
&#8220;domain names&#8221; we will continue to get idiots like myself wonder=
ing if you just want the zone cuts. &nbsp;(You don&#8217;t.)</span></div><di=
v style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 1=
4px;"><span style=3D"font-size: 18px;"><br></span></div><span id=3D"OLK_SRC_BODY=
_SECTION" style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font=
-size: 14px;"><blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BOR=
DER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div =
dir=3D"ltr"><span style=3D"font-size: 18px;"><br></span><span style=3D"font-size: =
18px;">
The particular issue is that there is structure imposed by users and by the=
 domain name registration system that is independent of the architecture and=
 protocol upon which the DNS is built.</span><span style=3D"font-size: 18px;">=
<br></span></div></div></div></blockquote></span><div style=3D"color: rgb(0, 0=
, 0); font-family: Calibri, sans-serif; font-size: 14px;"><span style=3D"font-=
size: 18px;"><br></span></div><div style=3D"color: rgb(0, 0, 0); font-family: =
Calibri, sans-serif; font-size: 14px;"><span style=3D"font-size: 18px;">That i=
s right. &nbsp;But the wording just doesn&#8217;t seen to get to the bottom =
of it. &nbsp;Perhaps:</span></div><div style=3D"color: rgb(0, 0, 0); font-fami=
ly: Calibri, sans-serif; font-size: 14px;"><span style=3D"font-size: 18px;"><b=
r></span></div><div><font face=3D"Calibri,sans-serif"><span style=3D"font-size: =
18px;">Given two identifiers that&nbsp;happen to correspond to DNS domain na=
mes, the temptation has been to seek a solution that emphasizes the nature a=
nd design of the DNS protocol. &nbsp;This needs to be resisted; instead a so=
lution Is needed that emphasizes the needs of the applications using the ide=
ntifiers, not merely what the DNS can offer. &nbsp;An example of failing to =
do this inappropriate reliance on the Public Suffix List. &nbsp;The PSL is (=
take the definition from below &amp; mention that the PSL means&nbsp;&#8220;=
yet another registry&#8221; and all the inherent pratfalls (yes, pratfalls) =
that come with running a registry, especially one that is a&nbsp;&#8220;thir=
d party&#8221; to the elements involved.</span></font></div><div style=3D"colo=
r: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;"><span s=
tyle=3D"font-size: 18px;"><br></span></div><span id=3D"OLK_SRC_BODY_SECTION"><bl=
ockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"border-left-color: r=
gb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding=
: 0px 0px 0px 5px; margin: 0px 0px 0px 5px;"><div dir=3D"ltr"><font face=3D"Cali=
bri,sans-serif"><span style=3D"font-size: 18px;">&#8230;&nbsp;</span></font></=
div></blockquote></span><div><br></div><div><div><font face=3D"Calibri,sans-se=
rif"><span style=3D"font-size: 18px;">The definition below:</span></font></div=
></div><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><blockquote id=3D"MAC_OU=
TLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"border-left-color: rgb(181, 196, 223); =
border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; =
margin: 0px 0px 0px 5px;"><div dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); f=
ont-family: Calibri, sans-serif; font-size: 18px;">Currently, the only solut=
ion in existence is maintained by a web browser producer, known as the Publi=
c Suffix List.&nbsp; This list, which is maintained by volunteers on a best-=
effort basis, contains a list of points in the DNS tree at which registratio=
ns take place.&nbsp;
 When this list is inaccurate, it exposes a deviation with reality that deg=
rades service to some and can be exploited by others.</span><br></div></bloc=
kquote></span></body></html>

--B_3499693809_32398051--

--B_3499693809_32380106
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTLq/THaDTvWcpYvbxU
trZ5KlBGNDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjQyMjEwMDlaMA0GCSqGSIb3DQEBAQUABIIBADMAdubQv+9G6ihTmEGjiS6z8LG/Y1QAbBy8
xGFob2Xhw0CAcc7VPcrEySQcxJq9eF9GLYkchELqgk7w0sAX1UzizVth8av93aGR/q8aLvy4
dXSkw4jbnI8ydybJRUFRl1Ei/px3n7h9ArMbRjIBM3sCx91IUS3BqLpzXRyc7QgDgCyeLkvN
i/BnozcXi2QtJV23cVB/F3d+Gr/dJBLl4f89o6pBsfWGrXLXFjvB+t/HPSCyMJZfxz6NKzSc
inkA/w5lgXCE9/90lQUDvQ1WZeXJwBIL8qxGtqrR6t4LfI51voXCEwZXj0vHtLXnuNfYCGUG
zbKR2q0IfwmqQ4FABlw=

--B_3499693809_32380106--


From nobody Mon Nov 24 14:25:34 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C821A6FB7 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOO5sH8kIb4M for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:25:29 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D65F1A1A34 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:25:29 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id x12so13817666wgg.5 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TB0+m1XYY1AxJvQHfbyk39EM00ZXOa0P/o+H3DxQXu8=; b=OQZtSsXCJYShNJZa+zoizU40hH/uX2fSFR3gzPmreBfLfMjot5eeh5fNnx9v9WQL7g 3iMFsMHtPsE7GV//6F/6V9lJXaz8q1oRBJ7YA9aYxDqceldiOeCYI5I4M1Sfd5gG5Hsj USBI3IE66VcLDt5L6GSgaOreBuMnowCiHSHJnb06m3y5UVx6oxEVQQ4prZuNfXwgVg5m x9mkXY56haV59THXPtJV49G1ljuuwRWven5CZ+KtP0n7f0/V7YKFgggG1VVnZtO08YlQ CMyL8puHPUhO0chlgpt9IiRCFia9JFJftJOPeHR3SJg/KUaE/56oosnsOdHJjOesRb3K Kj/g==
MIME-Version: 1.0
X-Received: by 10.180.74.39 with SMTP id q7mr25368579wiv.30.1416867928095; Mon, 24 Nov 2014 14:25:28 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 14:25:27 -0800 (PST)
In-Reply-To: <18167801.pVObHAHZSv@kitterman-optiplex-9020m>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <B78F986A-3A43-4FF6-99B2-08E7792FD03A@kitterman.com> <CAL0qLwZ50M2X+qGmSQB+Agi-FT1D0dmSCntvBhgXja0VO98Hrw@mail.gmail.com> <18167801.pVObHAHZSv@kitterman-optiplex-9020m>
Date: Mon, 24 Nov 2014 14:25:27 -0800
Message-ID: <CAL0qLwavpfnWhQmZjpXEHf2Nqr4-7AguR03f-ixhhJUFBgoFEQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Content-Type: multipart/alternative; boundary=f46d04374abf8c41750508a2458e
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/dv8cpvW2Ejt2828gAANmqmm0dqc
Cc: dbound@ietf.org
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:25:31 -0000

--f46d04374abf8c41750508a2458e
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 1:09 PM, Scott Kitterman <sklist@kitterman.com>
wrote:

> > Speaking completely hypothetically, could SPF not benefit from this today
> > if it became available?
>
> Not in a backwards compatible way.
>
> If there were to be a future non-backward compatible update to SPF, then
> yes,
> it would be useful, but I consider that unlikely anytime soon.  It's
> certainly
> not a significant rationale for doing the dbound work (which I think is
> good
> work to do for other reasons).
>

OK.  I wasn't really pushing for that; I was just using my imagination and
thought it might be an interesting use case.  I'll drop it from the text.

-MSK

--f46d04374abf8c41750508a2458e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 1:09 PM, Scott Kitterman <span dir=
=3D"ltr">&lt;<a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">skli=
st@kitterman.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><=
div class=3D"h5">&gt; Speaking completely hypothetically, could SPF not ben=
efit from this today<br>
&gt; if it became available?<br>
<br>
</div></div>Not in a backwards compatible way.<br>
<br>
If there were to be a future non-backward compatible update to SPF, then ye=
s,<br>
it would be useful, but I consider that unlikely anytime soon.=C2=A0 It&#39=
;s certainly<br>
not a significant rationale for doing the dbound work (which I think is goo=
d<br>
work to do for other reasons).<br></blockquote><div><br></div><div>OK.=C2=
=A0 I wasn&#39;t really pushing for that; I was just using my imagination a=
nd thought it might be an interesting use case.=C2=A0 I&#39;ll drop it from=
 the text.<br><br></div><div>-MSK <br></div></div></div></div>

--f46d04374abf8c41750508a2458e--


From nobody Mon Nov 24 14:30:42 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781C61A86EE for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znxd6aZ8E-t6 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:30:26 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FF21A8749 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:30:26 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id r20so7481344wiv.8 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bESz4Gnus66qYbiK2276vi5c13wIMOoHElS5P2+dHVs=; b=QDVIvXAAcB+go8mr5RenmtyNuAwihnFc5uQgZP49hdP0caXKX8Li6jbj7iuMsnEZAF bQNgYCzFRHk3lolbLlRdUgNm+ngjSV71lZZwqfZ17NDCwCymd4OWMnorDpq+tIsuMJXS Mm6N6qyQIq5iEskldqmr7aTmh/PodiueK+1h7Rtxb7nrz02wXh5zJ7kUDZA9h6t0M0ey 4kvsjvXUqfBq7rNLXtfNbc5UzD0ve1eV5Jn2Zg0A/ClmjZ2iWhqC7U98eNDUjqZUnnBu 2FaRzUaE3iRdBnwOLElMe9ICCC/YtGlRxBvi1QiUTvzwfiBWWlnNEAoxb3Plvd5U5KD1 PyVQ==
MIME-Version: 1.0
X-Received: by 10.194.103.232 with SMTP id fz8mr38731693wjb.110.1416868225215;  Mon, 24 Nov 2014 14:30:25 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 14:30:25 -0800 (PST)
In-Reply-To: <D099140A.7283%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org>
Date: Mon, 24 Nov 2014 14:30:25 -0800
Message-ID: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary=047d7bf109f041f6480508a2575a
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/x5gbvCBLXmQMN6TgmRLXs9kbDWo
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:30:34 -0000

--047d7bf109f041f6480508a2575a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 24, 2014 at 2:10 PM, Edward Lewis <edward.lewis@icann.org>
wrote:

>
>
> Various Internet protocols and applications require some mechanism for
> determining whether two Domain Name System (DNS) names are related.  A
> popular example is the need to determine whether example.com and
> foo.example.com are related; though to humans the answer to this may be
> obvious, it is difficult to establish this programatically.
>
>
> I would change this to : require some mechanism for determining whether
> two identifiers (based on Domain Name System names) are related.
>

OK.


> This is a pain-in-the-neck, pedantic comment but unless we can get folks
> to think =E2=80=9Cidentifiers=E2=80=9D and not =E2=80=9Cdomain names=E2=
=80=9D we will continue to get
> idiots like myself wondering if you just want the zone cuts.  (You don=E2=
=80=99t.)
>

Uh oh.  I thought that's exactly what we want (or, more precisely, we're
looking for one particular zone cut of interest).  What nuance of the term
"zone cut" am I missing?


> Given two identifiers that happen to correspond to DNS domain names, the
> temptation has been to seek a solution that emphasizes the nature and
> design of the DNS protocol.  This needs to be resisted; instead a solutio=
n
> Is needed that emphasizes the needs of the applications using the
> identifiers, not merely what the DNS can offer.  An example of failing to
> do this inappropriate reliance on the Public Suffix List.  The PSL is (ta=
ke
> the definition from below & mention that the PSL means =E2=80=9Cyet anoth=
er
> registry=E2=80=9D and all the inherent pratfalls (yes, pratfalls) that co=
me with
> running a registry, especially one that is a =E2=80=9Cthird party=E2=80=
=9D to the elements
> involved.
>

Thanks, I'll fold that (or some parts of it) into the text and see what
comes out.

-MSK

--047d7bf109f041f6480508a2575a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 2:10 PM, Edward Lewis <span dir=3D=
"ltr">&lt;<a href=3D"mailto:edward.lewis@icann.org" target=3D"_blank">edwar=
d.lewis@icann.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div style=3D"word=
-wrap:break-word"><span class=3D""><span style=3D"color:rgb(0,0,0);font-fam=
ily:Calibri,sans-serif;font-size:14px"><blockquote style=3D"BORDER-LEFT:#b5=
c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5"><div><span style=3D"font-size:=
18px"></span><div><div dir=3D"ltr"><div><span style=3D"font-size:18px"><br>=
</span></div><div><span style=3D"font-size:18px">Various Internet protocols=
 and applications require some mechanism for determining whether two Domain=
 Name System (DNS) names are related.=C2=A0 A popular example is the need t=
o determine whether
</span><a href=3D"http://example.com" target=3D"_blank"><span style=3D"font=
-size:18px">example.com</span></a><span style=3D"font-size:18px"> and </spa=
n><a href=3D"http://foo.example.com" target=3D"_blank"><span style=3D"font-=
size:18px">
foo.example.com</span></a><span style=3D"font-size:18px"> are related; thou=
gh to humans the answer to this may be obvious, it is difficult to establis=
h this programatically.</span></div></div></div></div></blockquote></span><=
div style=3D"color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px=
"><span style=3D"font-size:18px"><br></span></div></span><div style=3D"colo=
r:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><span style=3D"=
font-size:18px">I would change this to : require some mechanism for determi=
ning whether two identifiers (based on Domain Name System names) are relate=
d.</span></div></div></blockquote><div><br></div><div>OK.<br>=C2=A0<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div s=
tyle=3D"color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><sp=
an style=3D"font-size:18px">This is a pain-in-the-neck, pedantic comment bu=
t unless we can get folks to think =E2=80=9Cidentifiers=E2=80=9D and not =
=E2=80=9Cdomain names=E2=80=9D we will continue to get idiots like myself w=
ondering if you just want the zone cuts. =C2=A0(You don=E2=80=99t.)</span><=
/div></div></blockquote><div><br></div><div>Uh oh.=C2=A0 I thought that&#39=
;s exactly what we want (or, more precisely, we&#39;re looking for one part=
icular zone cut of interest).=C2=A0 What nuance of the term &quot;zone cut&=
quot; am I missing?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D""><div><font face=3D"Calibri,sans-serif"><span style=3D"font-size=
:18px">Given two identifiers that=C2=A0happen to correspond to DNS domain n=
ames, the temptation has been to seek a solution that emphasizes the nature=
 and design of the DNS protocol.=C2=A0 This needs to be resisted; instead a=
 solution Is needed that emphasizes the needs of the applications using the=
 identifiers, not merely what the DNS can offer.=C2=A0 An example of failin=
g to do this inappropriate reliance on the Public Suffix List.=C2=A0 The PS=
L is (take the definition from below &amp; mention that the PSL means=C2=A0=
=E2=80=9Cyet another registry=E2=80=9D and all the inherent pratfalls (yes,=
 pratfalls) that come with running a registry, especially one that is a=C2=
=A0=E2=80=9Cthird party=E2=80=9D to the elements involved.</span></font></d=
iv></span></blockquote><div><br></div>Thanks, I&#39;ll fold that (or some p=
arts of it) into the text and see what comes out.<br><br>-MSK<br></div></di=
v></div>

--047d7bf109f041f6480508a2575a--


From nobody Mon Nov 24 14:43:38 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1EE1A0250 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv9PN89Hu-8G for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:43:33 -0800 (PST)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5394A1A6FB7 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:43:33 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hi2so7457614wib.11 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cJYlT0haXnlyzAqm3InyApsitnDty8UosfER2spVQl0=; b=c7+NdFf521c0fCvaCaxW53gSyiCiL8ykKzCA3nZNe1DLTIhHsSGfHl98FmGIqsTuhH cwUgE8kAweY4n/bL/Pl9thYyaiZxcg8JMjUKOFB7mmLuOUxLTbCx2grUyXBeElWep7wH Jejxh6btXuGGieT7Rx83gcBzlSbxYqhgEo7esrafZw6yN10SrIpGqlvlyFkjrOyo6iii DTc2sQzInbB3WTkunu43I2dZk4EZ8i5OxT7Z9yNdtfIEcKyFler6izGFtetD5wG8Vb0D OL7XfDSYs2cM35FMdbDRoSiNDCDdh+lRj9spuMJRxL9pT3Wb9LcQLC1Pu7j1IqVYu/dn iB0A==
MIME-Version: 1.0
X-Received: by 10.180.102.98 with SMTP id fn2mr18194830wib.61.1416869012116; Mon, 24 Nov 2014 14:43:32 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 14:43:32 -0800 (PST)
In-Reply-To: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
Date: Mon, 24 Nov 2014 14:43:32 -0800
Message-ID: <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Edward Lewis <edward.lewis@icann.org>, Scott Kitterman <scott@kitterman.com>
Content-Type: multipart/alternative; boundary=f46d0444ef3b291bed0508a2861f
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/l1zrmGcSk4WsfIgERpEEA0LiKSg
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:43:37 -0000

--f46d0444ef3b291bed0508a2861f
Content-Type: text/plain; charset=UTF-8

Better?  (Ignore the two typos, they're already fixed in my repo copy)

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether example.com
and foo.example.com are related; although to humans the answer to this may be
obvious, it is difficult to establish this programatically since the right
answer is not always "compare the rightmost two labels".

The particular issue is that there is structure imposed by users and by the
domain name registration system that is independent of the architecture and
protocol upon which the DNS is built.  Stated more generally, given two
identifiers that happen to correspond to DNS domain names, the temptation
thus far has been to seek a solution that emphasizes the nature and design of
the DNS protocol.  This needs to be resisted; instead, a solution is needed
that emphasizes the needs of the applications using the identifiers, not
merely what the DNS can offer.

Currently, the only solution in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is kept current
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.  When this list is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.  It amounts to a third set of semantics imposed upon
the DNS from without, creating unrealistic expectations and eventually
solving the wrong problem.

In terms of specific use cases: Within the realm of email, there is a
desire to map an arbitrary domain name to the registered domain name
somewhere in the tree above it, in order to identify a deterministic
location where some sort of statement of policy regarding that domain
name can be found.  With respect to the web, there is a similar practice
of identifying domains as related as long as they share a common ancestor.
However, there is an additional need for the capability to declare
relationships between arbitrary names.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, and equivalence problems
require independent solutions, in which case the working group will follow
that path.  The solutions may or may not involve changes to the DNS, such
as creation of new resource record types; in any case, all such changes
will be incremental only.

This working group will not seek to amend the consumer protocols themselves
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
need to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD

--f46d0444ef3b291bed0508a2861f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Better?=C2=A0 (Ignore the two typos, they&#39;re already f=
ixed in my repo copy)<br><br><pre>dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether <a href=3D=
"http://example.com">example.com</a>
and <a href=3D"http://foo.example.com">foo.example.com</a> are related; alt=
hough to humans the answer to this may be
obvious, it is difficult to establish this programatically since the right
answer is not always &quot;compare the rightmost two labels&quot;.

The particular issue is that there is structure imposed by users and by the
domain name registration system that is independent of the architecture and
protocol upon which the DNS is built.  Stated more generally, given two
identifiers that happen to correspond to DNS domain names, the temptation
thus far has been to seek a solution that emphasizes the nature and design =
of
the DNS protocol.  This needs to be resisted; instead, a solution is needed
that emphasizes the needs of the applications using the identifiers, not
merely what the DNS can offer.

Currently, the only solution in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is kept curren=
t
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.  When this list is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.  It amounts to a third set of semantics imposed upon
the DNS from without, creating unrealistic expectations and eventually
solving the wrong problem.

In terms of specific use cases: Within the realm of email, there is a
desire to map an arbitrary domain name to the registered domain name
somewhere in the tree above it, in order to identify a deterministic
location where some sort of statement of policy regarding that domain
name can be found.  With respect to the web, there is a similar practice
of identifying domains as related as long as they share a common ancestor.
However, there is an additional need for the capability to declare
relationships between arbitrary names.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, and equivalence problem=
s
require independent solutions, in which case the working group will follow
that path.  The solutions may or may not involve changes to the DNS, such
as creation of new resource record types; in any case, all such changes
will be incremental only.

This working group will not seek to amend the consumer protocols themselves
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
need to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD
</pre><br></div>

--f46d0444ef3b291bed0508a2861f--


From nobody Mon Nov 24 14:53:12 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F011A89B5 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVVqz2PHc58A for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:53:10 -0800 (PST)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627DE1A6EFB for <dbound@ietf.org>; Mon, 24 Nov 2014 14:53:10 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id l2so3122879wgh.13 for <dbound@ietf.org>; Mon, 24 Nov 2014 14:53:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WsAXwYVGyWwWVSSU+Mfcr8HjirLTSW+EL9dM1G1Iyvc=; b=dUdz9YyPFzAsi/QqMatWsRuzw8ULD+Ls6iG7qrmp8zDvuxb12EbbaLEGEX0caNFQm4 KmQ1zS6N8645SYbeinbtAIaBzqcZr5n3wt5ZHfMTp6QDMoYNAaxYwAqtfBL9tzRLBbzx PTZQdHgtakG6zfpZ3SRZbDvw3MFtGFuc+I0fycKh4xYUHaW8qSyCvAeZPuGesHCitRCj 6vNC9Jx6D5vMWUxPKh8KgQhd5b3ek6WEA13Z/6fUyJKo/8q1nws1E7Y1fDCM6nVN/Cn6 4G+kFKRxYVG3g93QM+X2H4a3rDjIy27yuZcseDvH2GsoWkaRFW17CNLiwLdDgiF94r51 91gQ==
MIME-Version: 1.0
X-Received: by 10.194.3.2 with SMTP id 2mr38466625wjy.89.1416869589223; Mon, 24 Nov 2014 14:53:09 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 14:53:09 -0800 (PST)
In-Reply-To: <alpine.OSX.2.11.1411171643500.18601@ary.lan>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com> <alpine.OSX.2.11.1411171643500.18601@ary.lan>
Date: Mon, 24 Nov 2014 14:53:09 -0800
Message-ID: <CAL0qLwZt5UPxbLGAJgMc=cgGtSFwtLLL8Km0fsCuHamYHJjeGQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=047d7b343c188f0fd80508a2a8d5
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/9pvpvfR9U9PMIrMYbFOsaYKZTZc
Cc: Casey Deccio <casey@deccio.net>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:53:12 -0000

--047d7b343c188f0fd80508a2a8d5
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 1:50 PM, John R Levine <johnl@taugh.com> wrote:

> Every application I've seen for the PSL asks one of these three questions:
>
> * Are names A and B under the same authority? (the cookie question)
>
> * Are all the names covered by this wildcard under the same authority?
> (the cert question)
>
> * What's the shortest* name under the same authority as this one? (the
> DMARC question)
>
> None of those answers seem to me to make any sort of public/private
> distinction.
>

Aren't the first and third questions really the same one?  Or am I showing
a lot of email bias by asking that?

-MSK

--047d7b343c188f0fd80508a2a8d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 17, 2014 at 1:50 PM, John R Levine <span dir=
=3D"ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@tau=
gh.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Every application I&#39;ve seen f=
or the PSL asks one of these three questions:<br>
<br>
* Are names A and B under the same authority? (the cookie question)<br>
<br>
* Are all the names covered by this wildcard under the same authority? (the=
 cert question)<br>
<br>
* What&#39;s the shortest* name under the same authority as this one? (the =
DMARC question)<br>
<br>
None of those answers seem to me to make any sort of public/private distinc=
tion.<br></blockquote><div><br></div><div>Aren&#39;t the first and third qu=
estions really the same one?=C2=A0 Or am I showing a lot of email bias by a=
sking that?<br><br>-MSK<br></div></div></div></div>

--047d7b343c188f0fd80508a2a8d5--


From nobody Mon Nov 24 14:57:29 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876071A8749 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHa1wE_QpPWS for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 14:57:24 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DFB1A6EFB for <dbound@ietf.org>; Mon, 24 Nov 2014 14:57:24 -0800 (PST)
Received: (qmail 47447 invoked from network); 24 Nov 2014 22:57:22 -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=b955.5473b7d2.k1411; bh=NB+JCmj2wZAYg/LZW/nD83ixWPmBNHXnnuQMtvoikFc=; b=0pfeZjiKq/lcTgSJphguNh2MYtQKg7haQDVBFDZ6R2vPxZxbbFZLyvvHSlFmuUtYH6+cUG9TXlKTzYADnJbtqM2R95KOKx8003YyfYVXqOXr8Ak770mHudePA8k2VpnP/F23M5m5E0L30k1h6fioYcx9DQbcfPF0zOtiMbnOaO7JkLv/f6nzA49X6oVfdWXnLOpWeHe6lYL4Ga80/NRyX73F7kKAXpQ7Q5P+Zfz4dSrUX4lpjcjx9sTBPlhuY1Mn
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=b955.5473b7d2.k1411; bh=NB+JCmj2wZAYg/LZW/nD83ixWPmBNHXnnuQMtvoikFc=; b=EDQLBFV5x8gKHYbxaGTilUch0U22J9KW95UavDmHjLq4IPIRlWEBns7oUIMYk4OLS85X8gZk+9AVs/xwzyuqwzxb3gIKSbRIvfWKZ/GVHhyHLqZuVe4gpkwiUKMkm3AZkV8dR7yEz3gOdcCt/+91Uvw8B58poiZj4cSEmD6DwMo4gZDKDUxza1Le515/YjS47ndx6eWgFQi5exyFCdOJv1GcsUvp1ahuXXEdCKsrWExhjEbzrmTR0kAI4e7Ag1P5
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; 24 Nov 2014 22:57:22 -0000
Date: 24 Nov 2014 17:57:22 -0500
Message-ID: <alpine.OSX.2.11.1411241754190.58756@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
In-Reply-To: <CAL0qLwZt5UPxbLGAJgMc=cgGtSFwtLLL8Km0fsCuHamYHJjeGQ@mail.gmail.com>
References: <CAGrS0FK6Z182KN9gt=YcXdRJqPy2nUpvYcSOd+HjoKKAKOfDGQ@mail.gmail.com> <20141117190447.17052.qmail@ary.lan> <CAEKtLiSDw4-0fRCsTGzNmO61tNLWLc2OS1jer6Zy6LxNkoVZQQ@mail.gmail.com> <alpine.OSX.2.11.1411171643500.18601@ary.lan> <CAL0qLwZt5UPxbLGAJgMc=cgGtSFwtLLL8Km0fsCuHamYHJjeGQ@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/3CowmQB0wh4Grv1WEw_JvCFKBxE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] public/private, was multiple PSL-equivalents exist
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 22:57:25 -0000

>> Every application I've seen for the PSL asks one of these three questions:
>>
>> * Are names A and B under the same authority? (the cookie question)
>>
>> * Are all the names covered by this wildcard under the same authority? (the cert question)
>>
>> * What's the shortest* name under the same authority as this one? (the DMARC question)

> Aren't the first and third questions really the same one?  Or am I showing
> a lot of email bias by asking that?

Only if you rule out cross tree links, e.g. youtube.com is under the same 
authority as google.com.  Someone (Kurt?) said that it would be useful to 
do that for DMARC, although the current PSL implementation can't.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Mon Nov 24 15:29:56 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EB51A7004 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdDI7MnNs5C1 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:29:53 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13961A0250 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:29:52 -0800 (PST)
Received: (qmail 51161 invoked from network); 24 Nov 2014 23:29:50 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 24 Nov 2014 23:29:50 -0000
Date: 24 Nov 2014 23:29:29 -0000
Message-ID: <20141124232929.22844.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/khsHXilpZZwy4AbOJ05mBdqtXAM
Cc: superuser@gmail.com
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 23:29:53 -0000

>> I would change this to : require some mechanism for determining whether
>> two identifiers (based on Domain Name System names) are related.
>
>OK.

Not OK.  Really, we're looking at domain names.  If someone, despite all our
advice to the contrary, imagines that we're talking about zone cuts, that's
not our problem.

>Uh oh.  I thought that's exactly what we want (or, more precisely, we're
>looking for one particular zone cut of interest).  What nuance of the term
>"zone cut" am I missing?

Zone cuts have no particular connection to authority.  There are
plenty of places with the same authority on both sides of the cut, and
a smaller but still significant number where names in the same zone
are under different authorities, e.g., all of the blogs at
<name>.blogger.com or the subdomains of uk.com.

Also don't forget my note about cross-tree relationships.  I doubt
we'll be able to find a practical way to represent them, but if we
could, it would be very useful.

R's,
John


From nobody Mon Nov 24 15:49:35 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDEC1A871E for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:49:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVGm8FoE3NiP for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:49:32 -0800 (PST)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF381A89B5 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:49:32 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id l15so7623865wiw.4 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IeX6UwEgsIdg28vNfixcg97Rp+pltvGs0KGa8H25hu0=; b=Ac1L1BICu1wPSl/EiFSMZm8hN5cesOYnb7j0SUs6s8Kk7+ECrrAnmAgV7YrJHzM2l0 k7taHr5plBDLGK1s1yI6wFKR0UcV5W5w1c5kzoLpG3Rr9+9k8i0NT5tby/WY4lSRU1tH ZBY7erCIPyItkNx6mpx0Vcd0wtPBqWEjsK24JAeqZDRaWdCZvitAEIK+XqBLxMIRbnib eM02EcEvkX8lF5+FXU6jB0P8yxfB28X2u6pSEyhs5gpJ41AOoeSH/YY7flBWIngDobjf WGcD6MfZs9EFgKyxnWYJ4elchiI5tk+rkMvBXjDVaDr0aJSYDJ5pdR6CqibJ1UWz6DJC NZJg==
MIME-Version: 1.0
X-Received: by 10.194.3.2 with SMTP id 2mr38782745wjy.89.1416872970989; Mon, 24 Nov 2014 15:49:30 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 15:49:30 -0800 (PST)
In-Reply-To: <20141124232929.22844.qmail@ary.lan>
References: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <20141124232929.22844.qmail@ary.lan>
Date: Mon, 24 Nov 2014 15:49:30 -0800
Message-ID: <CAL0qLwbsMq2mGbevTx8rexD6kTBjSXFywgT-HpOBGvUrgWwSQg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=047d7b343c1820b6ea0508a3723c
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ucqbkx4boz-1b3B_s_MDon7QI3E
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 23:49:34 -0000

--047d7b343c1820b6ea0508a3723c
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 3:29 PM, John Levine <johnl@taugh.com> wrote:

> >> I would change this to : require some mechanism for determining whether
> >> two identifiers (based on Domain Name System names) are related.
> >
> >OK.
>
> Not OK.  Really, we're looking at domain names.  If someone, despite all
> our
> advice to the contrary, imagines that we're talking about zone cuts, that's
> not our problem.
>

I took Ed's comment to mean that we're really talking about a domain name
which in the DNS sense is just another name, but to humans who think
outside of the DNS, it is more than just another name.


> >Uh oh.  I thought that's exactly what we want (or, more precisely, we're
> >looking for one particular zone cut of interest).  What nuance of the term
> >"zone cut" am I missing?
>
> Zone cuts have no particular connection to authority.  There are
> plenty of places with the same authority on both sides of the cut, and
> a smaller but still significant number where names in the same zone
> are under different authorities, e.g., all of the blogs at
> <name>.blogger.com or the subdomains of uk.com.
>

So should we use neither term?  The term "authority" also harkens to the
presence of an SOA which, like a zone cut, doesn't necessarily tell you
anything if it's there.


> Also don't forget my note about cross-tree relationships.  I doubt
> we'll be able to find a practical way to represent them, but if we
> could, it would be very useful.
>

Right, I agree.  Does the latest charter text cover it or do you have a
suggested change?

-MSK

--047d7b343c1820b6ea0508a3723c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 3:29 PM, John Levine <span dir=3D"=
ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.c=
om</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt;&gt; I would cha=
nge this to : require some mechanism for determining whether<br>
&gt;&gt; two identifiers (based on Domain Name System names) are related.<b=
r>
&gt;<br>
&gt;OK.<br>
<br>
</span>Not OK.=C2=A0 Really, we&#39;re looking at domain names.=C2=A0 If so=
meone, despite all our<br>
advice to the contrary, imagines that we&#39;re talking about zone cuts, th=
at&#39;s<br>
not our problem.<br></blockquote><div><br></div><div>I took Ed&#39;s commen=
t to mean that we&#39;re really talking about a domain name which in the DN=
S sense is just another name, but to humans who think outside of the DNS, i=
t is more than just another name.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<span class=3D"">&gt;Uh oh.=C2=A0 I thought that&#39;s exactly what we want=
 (or, more precisely, we&#39;re<br>
&gt;looking for one particular zone cut of interest).=C2=A0 What nuance of =
the term<br>
&gt;&quot;zone cut&quot; am I missing?<br>
<br>
</span>Zone cuts have no particular connection to authority.=C2=A0 There ar=
e<br>
plenty of places with the same authority on both sides of the cut, and<br>
a smaller but still significant number where names in the same zone<br>
are under different authorities, e.g., all of the blogs at<br>
&lt;name&gt;.<a href=3D"http://blogger.com" target=3D"_blank">blogger.com</=
a> or the subdomains of <a href=3D"http://uk.com" target=3D"_blank">uk.com<=
/a>.<br></blockquote><div><br></div><div>So should we use neither term?=C2=
=A0 The term &quot;authority&quot; also harkens to the presence of an SOA w=
hich, like a zone cut, doesn&#39;t necessarily tell you anything if it&#39;=
s there.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also don&#39;t forget my note about cross-tree relationships.=C2=A0 I doubt=
<br>
we&#39;ll be able to find a practical way to represent them, but if we<br>
could, it would be very useful.<br></blockquote><div><br></div><div>Right, =
I agree.=C2=A0 Does the latest charter text cover it or do you have a sugge=
sted change?<br><br>-MSK<br></div></div></div></div>

--047d7b343c1820b6ea0508a3723c--


From nobody Mon Nov 24 15:51:49 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60111A89B5 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXYtjy6Bq88h for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:51:47 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C461A871E for <dbound@ietf.org>; Mon, 24 Nov 2014 15:51:47 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id y19so13715426wgg.7 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3dCwj975bDQUyqNT5epguRhXQLNkFWUYov1LKPc5dWc=; b=EDjFMPiMf6P5GgUP+96fzV+qanjz294Ufdq76Y8Ol3B27HlQL2fZk8/ArVeQJY5Ni5 /ThrM4LtOLpUy6gqwQp0mH2StB2PyeAHkYQeoI54qRPNdedqfrIBOB8Ats0yCb5E2TvN RrNpDTuSGKD/5+8dzlK1Wk33uHTtFE8xVKiHI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3dCwj975bDQUyqNT5epguRhXQLNkFWUYov1LKPc5dWc=; b=Pbl7madAlmuTLniZs2xYtuzp2Ms64pJD7vky748ftqS7qPwI3XNkUZvLiXb89BAqPf KTIHH8iknRru2pqGglIHA2CVJnA0Jnx9a1b5RrEdXCvj3aRsyDpVp47RaHc5nWICYfgG N/f1gtqzwCcgAV1Z7U1yyqz1C+EZ17XLbbNq+NKUXG0+6tMdZRtD5756SINNzOkYphjS 9aYk6AiZ7FQw9kCDd0Yux8wxiuqbDK9L5YrdkBvCnHqdbwnr68vSuE/jxtLRRZt5CFjK qrgBBloha6BBrtihy44tE8MTPX/pvfmZ17IGVK+3LebuwOlyn/Q6n+KzUpgjhwWxw67Y m4gA==
X-Gm-Message-State: ALoCoQm+/iSvHIpTVL/UcR8E/5Nz7CpwqmETqFU9Dz63+1jUST7VuoO5yPHiGz3pQBBY/rAMI7jM
MIME-Version: 1.0
X-Received: by 10.194.223.9 with SMTP id qq9mr39340472wjc.36.1416873106004; Mon, 24 Nov 2014 15:51:46 -0800 (PST)
Received: by 10.194.188.115 with HTTP; Mon, 24 Nov 2014 15:51:45 -0800 (PST)
In-Reply-To: <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
Date: Mon, 24 Nov 2014 15:51:45 -0800
Message-ID: <CABuGu1oJABALd1V_=L9s06vfCWc9h4Y2ovxcO6Q9rYKVpmhPnQ@mail.gmail.com>
From: Kurt Andersen <kurta@drkurt.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3aab02cfa180508a37abc
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/9QEiRGys6oy2MV6ZPiR2_v4kQbY
Cc: Edward Lewis <edward.lewis@icann.org>, Scott Kitterman <scott@kitterman.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 23:51:48 -0000

--001a11c3aab02cfa180508a37abc
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 2:43 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> In terms of specific use cases: Within the realm of email, there is a
> desire to map an arbitrary domain name to the registered domain name
> somewhere *in the tree above it* [emphasis added], in order to identify a
> deterministic location where some sort of statement of policy regarding
> that domain name can be found.


If we are interested in possible solutions that could include cross-domain
relationships of policy, why constrain the problem statement to
hierarchical relationships?

--Kurt

--001a11c3aab02cfa180508a37abc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On Mon, Nov 24, 2014 at 2:43 PM=
, Murray S. Kucherawy <span dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gma=
il.com" target=3D"_blank">superuser@gmail.com</a>&gt;</span> wrote:<br><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In terms of specific =
use cases: Within the realm of email, there is a
desire to map an arbitrary domain name to the registered domain name
somewhere *in the tree above it* [emphasis added], in order to identify a d=
eterministic
location where some sort of statement of policy regarding that domain
name can be found.</blockquote></div><br></div><div class=3D"gmail_extra">I=
f we are interested in possible solutions that could include cross-domain r=
elationships of policy, why constrain the problem statement to hierarchical=
 relationships?<br><br></div><div class=3D"gmail_extra">--Kurt<br></div><di=
v class=3D"gmail_extra"><br></div></div>

--001a11c3aab02cfa180508a37abc--


From nobody Mon Nov 24 15:57:20 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3214C1A8A72 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7icnB0aGzzr for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 15:57:17 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A207E1A871E for <dbound@ietf.org>; Mon, 24 Nov 2014 15:57:17 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id bs8so10674696wib.5 for <dbound@ietf.org>; Mon, 24 Nov 2014 15:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eOb+GyPpAEHGsC3wV47xZlyFgfouh0ZR6gj6c0QcrgY=; b=I//Oe8F8Qb136CV/Ia79htRyGOeAl5BAExq4oh4FjZb55M7J4wopi30LcSeAS7Cqiw 5FoZXmY3PdfREs+qYev6AHZPAz0ZiD/TJUJeyKnYZSyGMHkGU+Mk9nb8GL0h2TOyTLmB i+sT/p7kaKFY3LVLRwWbLRz/e+KO+EgZ3Zlkf0PyNfTdABwuyNzT9D0/wAEG06sBMQAn i06vBOCa+OlC8CzSqx1mg7eQderbd1DrHJeZOTukKYR4zLWofrHMjqYwl6KNVazCuV5B +oEVfI07z18NJH178KbxL11P1lCVem++9YoQSWh9ZSlFgccAHzUir9h2W5KOnQaMWC1g EXJw==
MIME-Version: 1.0
X-Received: by 10.194.62.76 with SMTP id w12mr20418125wjr.5.1416873436437; Mon, 24 Nov 2014 15:57:16 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Mon, 24 Nov 2014 15:57:16 -0800 (PST)
In-Reply-To: <CABuGu1oJABALd1V_=L9s06vfCWc9h4Y2ovxcO6Q9rYKVpmhPnQ@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <CABuGu1oJABALd1V_=L9s06vfCWc9h4Y2ovxcO6Q9rYKVpmhPnQ@mail.gmail.com>
Date: Mon, 24 Nov 2014 15:57:16 -0800
Message-ID: <CAL0qLwZocuUHB8srYePBN0LzNiWr9xb1Wavq9UtCpKU1Xr3eXQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Kurt Andersen <kurta@drkurt.com>
Content-Type: multipart/alternative; boundary=047d7ba977a4dee2f10508a38d02
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/xCacl0p6tfsuuWOBt3Xqq-hGwg0
Cc: Edward Lewis <edward.lewis@icann.org>, Scott Kitterman <scott@kitterman.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 23:57:19 -0000

--047d7ba977a4dee2f10508a38d02
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 3:51 PM, Kurt Andersen <kurta@drkurt.com> wrote:

>
> On Mon, Nov 24, 2014 at 2:43 PM, Murray S. Kucherawy <superuser@gmail.com>
> wrote:
>
>> In terms of specific use cases: Within the realm of email, there is a
>> desire to map an arbitrary domain name to the registered domain name
>> somewhere *in the tree above it* [emphasis added], in order to identify a
>> deterministic location where some sort of statement of policy regarding
>> that domain name can be found.
>
>
> If we are interested in possible solutions that could include cross-domain
> relationships of policy, why constrain the problem statement to
> hierarchical relationships?
>

That hasn't been a use case to date, meaning it has not been the impetus
for the work so far.  That's what this paragraph is describing.  I could
add an "Even better would be..." if you like.

--047d7ba977a4dee2f10508a38d02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 3:51 PM, Kurt Andersen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:kurta@drkurt.com" target=3D"_blank">kurta@dr=
kurt.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br><div dir=3D"ltr"><div class=
=3D"gmail_extra">On Mon, Nov 24, 2014 at 2:43 PM, Murray S. Kucherawy <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">s=
uperuser@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">In terms of specific use cases: Within the realm=
 of email, there is a
desire to map an arbitrary domain name to the registered domain name
somewhere *in the tree above it* [emphasis added], in order to identify a d=
eterministic
location where some sort of statement of policy regarding that domain
name can be found.</blockquote></div><br></div><div class=3D"gmail_extra">I=
f we are interested in possible solutions that could include cross-domain r=
elationships of policy, why constrain the problem statement to hierarchical=
 relationships?<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></=
span><span class=3D"HOEnZb"></span></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">That hasn&#39;t bee=
n a use case to date, meaning it has not been the impetus for the work so f=
ar.=C2=A0 That&#39;s what this paragraph is describing.=C2=A0 I could add a=
n &quot;Even better would be...&quot; if you like.<br></div></div>

--047d7ba977a4dee2f10508a38d02--


From nobody Mon Nov 24 16:38:12 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570441A6F53 for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 16:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPiZSPj0zUHz for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 16:38:09 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CB61A1B5D for <dbound@ietf.org>; Mon, 24 Nov 2014 16:38:09 -0800 (PST)
Received: (qmail 61293 invoked from network); 25 Nov 2014 00:38:06 -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=ef6c.5473cf6e.k1411; bh=aNho6X0C8Hxm8ESiczufasYpjjVOtso1/6La0bPqIhI=; b=oYJYOHLfMmovFdWfc9WJVrugf4MWmQhkm8kdM+v9erbKVGWLWt9zAuQgP0mHABSmjt6dOvhKx6GgfBmwzvrbMHiddPot9TsB8QpFwbiOuFuzYytw3KscjDE9/Kbj4tx3Vh1dMi+4R3IquizL4bKHNATjEa76r+nXcEwxJgtaRIO9sjD4hlF+XzNbClMEoyMku13RQ/PSXsVlUXcYttJyCfA3f+hdcpXyW04mDX+LmetP+Cw0Y6iQFGfh+5bAw2z3
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=ef6c.5473cf6e.k1411; bh=aNho6X0C8Hxm8ESiczufasYpjjVOtso1/6La0bPqIhI=; b=m98M2pq558UGzP+hFtAeYPOUvX2R7z6rjyXmXcKGVw0mcjSwr8AgrppZJyLb5F8ugV3H50UujL19FrXVmrcQwXEhgZkWTtaHef/nPtAMsoMDIWHzkf2KvdiInnHW4qHvOAl3LK+wVg6WemkSItW7p1uObEwnN9OO+WZSJ7mOE1lOmGWHHAas7dkUrzW4ItoN1gt9qXODa0Q5F9oyMOsbs3r6fF9XaidU4jr5SiHvAXJpHWcQ0bfMRAyVt/+11sQU
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; 25 Nov 2014 00:38:06 -0000
Date: 24 Nov 2014 19:38:06 -0500
Message-ID: <alpine.OSX.2.11.1411241934350.59252@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
In-Reply-To: <CAL0qLwbsMq2mGbevTx8rexD6kTBjSXFywgT-HpOBGvUrgWwSQg@mail.gmail.com>
References: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <20141124232929.22844.qmail@ary.lan> <CAL0qLwbsMq2mGbevTx8rexD6kTBjSXFywgT-HpOBGvUrgWwSQg@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/KyL3uPQgAb9q44OjLFspxVYIQJU
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 00:38:10 -0000

> I took Ed's comment to mean that we're really talking about a domain name
> which in the DNS sense is just another name, but to humans who think
> outside of the DNS, it is more than just another name.

Let's not get too metaphysical here.  The names are in the DNS, we're 
trying to represent some of the external semantics about how the names are 
or aren't related to each other.

> So should we use neither term?  The term "authority" also harkens to the
> presence of an SOA which, like a zone cut, doesn't necessarily tell you
> anything if it's there.

Good thought.  Let me check my thesaurus ... management?  control?

R's,
John


From nobody Mon Nov 24 19:10:08 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D721A802E for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 19:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nEsiRMGVXlo for <dbound@ietfa.amsl.com>; Mon, 24 Nov 2014 19:10:00 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C364B1A1B96 for <dbound@ietf.org>; Mon, 24 Nov 2014 19:09:59 -0800 (PST)
Received: (qmail 79347 invoked from network); 25 Nov 2014 03:09:58 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Nov 2014 03:09:58 -0000
Date: 25 Nov 2014 03:09:36 -0000
Message-ID: <20141125030936.23372.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAL0qLwZocuUHB8srYePBN0LzNiWr9xb1Wavq9UtCpKU1Xr3eXQ@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/9qFBhXrHYesVkL02fF3S537jJtM
Cc: superuser@gmail.com
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 03:10:02 -0000

>> If we are interested in possible solutions that could include cross-domain
>> relationships of policy, why constrain the problem statement to
>> hierarchical relationships?
>
>That hasn't been a use case to date, meaning it has not been the impetus
>for the work so far.  That's what this paragraph is describing.  I could
>add an "Even better would be..." if you like.

It was in Andrew's original draft.  Your wording is probably fine --
if we can do it, great, but I'm not holding my breath.

R's,
John


From nobody Tue Nov 25 07:09:04 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B255B1A6F67 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 07:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC9LdjX46ABz for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 07:08:56 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683951A6F97 for <dbound@ietf.org>; Tue, 25 Nov 2014 07:08:52 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id k14so1101377wgh.24 for <dbound@ietf.org>; Tue, 25 Nov 2014 07:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OcnZ8Fola1ZFZrF27P+TlV9+/uvXbPCRDrvEJ2YnNW8=; b=ISpmaewaOTyxWQ48qGnAZaxwnIFov8RXoS5bBrivSOlLnueY58pyACn1K8oMCqr67b dleN2Gqgtg+78PKDMeSczyS3SEzfTusUyxsuudDjleSHheExy6u2fFTf0xZBUUL9nb/N y+wVaG8xO1Yb7lkbKbr5ckvENO9WExSThkfILv8KcniAjGteacv0grvWp0NMg8o6CqI0 BTGX5BOow0M40ePEGEBUwiN5jb3rSslruzhn+THp0fuGozY3iXYeNOeOrZddRjhU8JQZ NgrX5x9hXpb4s2CAePTKRbd46RUg9/NKpcq2P9cLv1dhjrEtRKTJQlgizsuqWcVzhVzU NfDA==
MIME-Version: 1.0
X-Received: by 10.180.211.166 with SMTP id nd6mr31740103wic.81.1416928131174;  Tue, 25 Nov 2014 07:08:51 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Tue, 25 Nov 2014 07:08:51 -0800 (PST)
In-Reply-To: <alpine.OSX.2.11.1411241934350.59252@ary.lan>
References: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <20141124232929.22844.qmail@ary.lan> <CAL0qLwbsMq2mGbevTx8rexD6kTBjSXFywgT-HpOBGvUrgWwSQg@mail.gmail.com> <alpine.OSX.2.11.1411241934350.59252@ary.lan>
Date: Tue, 25 Nov 2014 07:08:51 -0800
Message-ID: <CAL0qLwbE2ODP=EmK0gnRTgUH7jm80KXvgQ-WXizsKsQPP-02vw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a11c264f2ee55420508b049ad
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Z3S23IjwcdxsKrlojJ6SkyStJAI
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 15:08:59 -0000

--001a11c264f2ee55420508b049ad
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 24, 2014 at 4:38 PM, John R Levine <johnl@taugh.com> wrote:

> I took Ed's comment to mean that we're really talking about a domain name
>> which in the DNS sense is just another name, but to humans who think
>> outside of the DNS, it is more than just another name.
>>
>
> Let's not get too metaphysical here.  The names are in the DNS, we're
> trying to represent some of the external semantics about how the names are
> or aren't related to each other.
>

So given the current text, what would you change?


>
>  So should we use neither term?  The term "authority" also harkens to the
>> presence of an SOA which, like a zone cut, doesn't necessarily tell you
>> anything if it's there.
>>
>
> Good thought.  Let me check my thesaurus ... management?  control?
>

The word "authority" doesn't actually appear in the current text, so I
guess we just need to keep it that way.

Any other changes we need to discuss?

-MSK

--001a11c264f2ee55420508b049ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 24, 2014 at 4:38 PM, John R Levine <span dir=
=3D"ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@tau=
gh.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
I took Ed&#39;s comment to mean that we&#39;re really talking about a domai=
n name<br>
which in the DNS sense is just another name, but to humans who think<br>
outside of the DNS, it is more than just another name.<br>
</blockquote>
<br></span>
Let&#39;s not get too metaphysical here.=C2=A0 The names are in the DNS, we=
&#39;re trying to represent some of the external semantics about how the na=
mes are or aren&#39;t related to each other.<span class=3D""><br></span></b=
lockquote><div><br></div><div>So given the current text, what would you cha=
nge?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
So should we use neither term?=C2=A0 The term &quot;authority&quot; also ha=
rkens to the<br>
presence of an SOA which, like a zone cut, doesn&#39;t necessarily tell you=
<br>
anything if it&#39;s there.<br>
</blockquote>
<br></span>
Good thought.=C2=A0 Let me check my thesaurus ... management?=C2=A0 control=
?<br></blockquote><div><br></div><div>The word &quot;authority&quot; doesn&=
#39;t actually appear in the current text, so I guess we just need to keep =
it that way.<br><br></div><div>Any other changes we need to discuss?<br><br=
></div><div>-MSK <br></div></div></div></div>

--001a11c264f2ee55420508b049ad--


From nobody Tue Nov 25 07:27:38 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC24D1A1F16 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 07:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaTiBWXDEKHe for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 07:27:34 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A411A1EFD for <dbound@ietf.org>; Tue, 25 Nov 2014 07:27:34 -0800 (PST)
Received: (qmail 72069 invoked from network); 25 Nov 2014 15:27:31 -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=11984.54749fe3.k1411; bh=wxZiESi/UZSHuSf0LSbHHmRGRudRWxVvick3zUpGBKw=; b=aLnt77pmWFvPBm3s5LSEWhecp8IN5uNHsEHHyNU5/kFdLzAEN2LFhGPToQGcHjSjcVDNCMbJdr1aMy2WgISa6t+3YXVbOKHWn9Pu0UGML+QkDonFptRPxNVEWWfJ/ygwIWShUjQm3jzUgPC+5Cc2ETlBfmVEQRSZSKxfeHhksSHUbBkk4vSkEaZSTzas/dTFBH6sj9B3HxZkJpGbArH66+1LSIb1Ha6UmOKllvzjjUCzRrVExIbV39A7f6mVP6Ix
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=11984.54749fe3.k1411; bh=wxZiESi/UZSHuSf0LSbHHmRGRudRWxVvick3zUpGBKw=; b=REwp8f16KEHmKJmJ9LDvIAqXvIKCJhHcK3WhmKwh7Dx7BEy6PLsZwbughOQGGg3yBeP+cP/LCZal01Z44B07sDU2+qsN+Nkb0n72//p5yi2N7CSPwjbHtKW0GE6C1aWuxdTZm7AmDIEPcKbHelb0vQfNy5/cHmrnmgaoAe1MeRvd/G/5+RBhfgdoJHOlS2OhDbhrbk9VpzRKrK0AY83B9KeY/VX7JhHVLNxyxDvtMDUgkfaabBNAv/9pewqzxl2F
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; 25 Nov 2014 15:27:31 -0000
Date: 25 Nov 2014 10:27:32 -0500
Message-ID: <alpine.OSX.2.11.1411251023260.60999@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
In-Reply-To: <CAL0qLwbE2ODP=EmK0gnRTgUH7jm80KXvgQ-WXizsKsQPP-02vw@mail.gmail.com>
References: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <20141124232929.22844.qmail@ary.lan> <CAL0qLwbsMq2mGbevTx8rexD6kTBjSXFywgT-HpOBGvUrgWwSQg@mail.gmail.com> <alpine.OSX.2.11.1411241934350.59252@ary.lan> <CAL0qLwbE2ODP=EmK0gnRTgUH7jm80KXvgQ-WXizsKsQPP-02vw@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/aQo_qwhTGz11sKRHCunzh2-jPKI
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 15:27:36 -0000

> So given the current text, what would you change?

> given two identifiers that happen to correspond to DNS domain names,
given two domain names

> using the identifiers
using the names

> somewhere in the tree above it
somewhere in the tree

> share a common ancestor
share a common ancestor under the same management

(note that google.com and evil-spammer.com share a common ancestor)

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Tue Nov 25 08:11:55 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5191A6F34 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPdTftR4YynB for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:11:51 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6611AC3D0 for <dbound@ietf.org>; Tue, 25 Nov 2014 08:10:23 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E25DA8A038 for <dbound@ietf.org>; Tue, 25 Nov 2014 16:10:21 +0000 (UTC)
Date: Tue, 25 Nov 2014 11:10:21 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125161021.GG5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/D8G_-Qwl4J2U8qA_QPjokKUkB88
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 16:11:52 -0000

On Mon, Nov 24, 2014 at 02:30:25PM -0800, Murray S. Kucherawy wrote:
> 
> Uh oh.  I thought that's exactly what we want (or, more precisely, we're
> looking for one particular zone cut of interest).  What nuance of the term
> "zone cut" am I missing?

A "zone cut" in DNS parlance is the place where NS records are
inserted at the delegation point, and NS records and an SOA record
exist at an apex.  It's literally a _zone_ cut: zones are boundaries
of DNS administrative convenience, and imply nothing about the policy
boundaries.  (SOA stands for "start of authority", and it means
authority in the DNS sense of authoritative server.)

You're right that there's an analogy between zone boundaries and
policy boundaries, which is how I settled on the Start Of Policy
Authority term (SOPA).  The collateral thumbing of nose at certain
misguided legislative proposals was merely a fringe benefit.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 08:12:16 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB41A1F04 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.559
X-Spam-Level: **
X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWr5toBaa0jP for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:12:14 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DED1AC3BB for <dbound@ietf.org>; Tue, 25 Nov 2014 08:11:58 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C1D358A038 for <dbound@ietf.org>; Tue, 25 Nov 2014 16:11:47 +0000 (UTC)
Date: Tue, 25 Nov 2014 11:11:47 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125161147.GH5479@mx1.yitter.info>
References: <CAL0qLwZocuUHB8srYePBN0LzNiWr9xb1Wavq9UtCpKU1Xr3eXQ@mail.gmail.com> <20141125030936.23372.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141125030936.23372.qmail@ary.lan>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/cjBtE9SG9PJww478Bl4KaOAScrM
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 16:12:15 -0000

On Tue, Nov 25, 2014 at 03:09:36AM -0000, John Levine wrote:
> It was in Andrew's original draft.  Your wording is probably fine --
> if we can do it, great, but I'm not holding my breath.

We can certainly express it; I already showed how.  The reason I
removed it was because people claimed that their existing code all
depended on hierarchical relationships and they weren't going to
change their code, so I took it out so that they'd stop yelling at me.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 08:24:45 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840881ACD64 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNNEp_6l5JAd for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 08:24:34 -0800 (PST)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013A81ACD23 for <dbound@ietf.org>; Tue, 25 Nov 2014 08:24:08 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id rd18so845435iec.22 for <dbound@ietf.org>; Tue, 25 Nov 2014 08:24:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rc4rDXCJaJwh6WAKp2BIz+D6DR7VjdQRbNsIuK8NTKw=; b=EV9OShZjhxsHLSanVtT4niLOyz+DnTY3ofj1ivzErMOxtRLO5nL5iZWtyxtq8X0YT6 me7Fag9/0HsHl2s4xDLkIQwygn+nUfWWLMCysFA7MHMvf6smAojTp9j35aazVrOmJ6CT JyJ4zE2LkaIgrfefQ8jHRHsejrF49BUqxG9WU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rc4rDXCJaJwh6WAKp2BIz+D6DR7VjdQRbNsIuK8NTKw=; b=Zb0QbHiAUFKk7U/ty1LAPBhNRyj0a7Bnl80cPXiuAmJ3aXhG6kTG6hTjF1APXhaMW1 x4ELpRcpZoCr413MLmLu3HF8JpROPAXJ63e0U3ysgwafzpNGttxhk8Uz7ew707+6BU3P 2PVdTsTJYMRqP+enQNchu5fpcW5/xEAdqSzscyFGiIe/Fpw3IEEgZYlkXnL4I5TvCBil 1iC0dnEay189utQfKw8X49CL0e61iA6FYYOm5vzFCIQyzJMLX5zFiKv7bRfUhvGAlh7z +Qd5kv9j6HyOjWL/am9LrWGKSWAFmO8Ou4nhjXITlddjluFvr28HAHDfQl+kKqyEzUdJ E8RQ==
X-Gm-Message-State: ALoCoQmr/QFIC9xEHAiTCoMYjIw700blQegELv2NYyNKKT3NwMrtC7hvSpQbYBBYO7BqjjsWG6bE
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr23570373ioo.73.1416932647075; Tue, 25 Nov 2014 08:24:07 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 25 Nov 2014 08:24:06 -0800 (PST)
In-Reply-To: <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
Date: Tue, 25 Nov 2014 11:24:06 -0500
Message-ID: <CAEKtLiRbbvA53YDf8EFVLBE6oBE1K8r9J545OLh-Y7MagCMnUg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a113703b4199a350508b157cf
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/7AEUUJbtEX_9CXAy24xQV_UJzIQ
Cc: Edward Lewis <edward.lewis@icann.org>, Scott Kitterman <scott@kitterman.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 16:24:36 -0000

--001a113703b4199a350508b157cf
Content-Type: text/plain; charset=UTF-8

Comments below:

On Mon, Nov 24, 2014 at 5:43 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Better?  (Ignore the two typos, they're already fixed in my repo copy)
>
>
OLD:

> Stated more generally, given two
> identifiers that happen to correspond to DNS domain names, the temptation
> thus far has been to seek a solution that emphasizes the nature and design of
> the DNS protocol.  This needs to be resisted; instead, a solution is needed
> that emphasizes the needs of the applications using the identifiers, not
> merely what the DNS can offer.
>
> NEW:

Historically, solutions for identifying relationships between domain names
have been based almost exclusively on the DNS namespace and protocol.
While this basis is often sufficient, the fact that it relies on
assumptions stemming from the nature of the DNS makes such solutions
unreliable and unnecessarily constrained.  For example, confirming or
dismissing a relationship between two domain names based on the existence
of a zone cut or common ancestry is often unfounded.

> Currently, the only solution in existence is maintained by a web browser
> producer, known as the Public Suffix List.  This list, which is kept current
> by volunteers on a best-effort basis, contains a list of points in the DNS
> tree at which registrations take place.
>
> NEW:

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the DNS tree at which registrations take place and is used to identify
the boundary between so-called "public" names (below which registrations
can occur) and the private names (i.e., registered names) below them.

>   When this list is inaccurate, it
> exposes a deviation with reality that degrades service to some and can be
> exploited by others.
>
>
COMMENT: While the above statement is true, this can be said about any
solution--even those produced by this WG.  So I'm not sure this sentence
adds anything useful, and I think it should be struck.

OLD:

>   It amounts to a third set of semantics imposed upon
> the DNS from without, creating unrealistic expectations and eventually
> solving the wrong problem.
>
> COMMENT: This sentence is subjective and is (in my opinion) much
overstating the problem.  See the restatement below.

NEW:

Being the de facto resource, and lacking a more comprehensive, alternative
solution for relationship identification, the functionality of the PSL has
often been misused to accomplish means beyond its capabilities.  For
example, there is no way to confirm the relationship between two domain
names, only signal that there is or is not a public boundary between the
two.

(OPTIONAL: Additionally, there are questions about the scalability, central
management, and third-party management of the PSL as it currently exists.)

In terms of specific use cases: Within the realm of email, there is a
> desire to map an arbitrary domain name to the
>
>
OLD:

> registered domain name
> somewhere in the tree above it,
>
> NEW:
organizational domain name (traditionally in the namespace above it),

>  in order to identify a deterministic
> location where some sort of statement of policy regarding that domain
> name can be found.
>
>
OLD:

> With respect to the web, there is a similar practice
> of identifying domains as related as long as they share a common ancestor.
>
> NEW:
With respect to the Web, there is a similar need to identify relationships
between different domains, currently accomplished by comparing ancestries.

OLD:

> However, there is an additional need for the capability to declare
> relationships between arbitrary names.
>
>
NEW:
However, there is also desire to reliably identify relationships outside of
the realm and constraints of the DNS namespace tree.

Regards,
Casey

--001a113703b4199a350508b157cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Comments below:<br><div><br>On Mon, Nov 24, 2014 at 5:43 P=
M, Murray S. Kucherawy <span dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gm=
ail.com" target=3D"_blank">superuser@gmail.com</a>&gt;</span> wrote:<br><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">Better?=C2=A0 (Ignore the two ty=
pos, they&#39;re already fixed in my repo copy)<br><br></div></blockquote><=
div><br></div><div>OLD: <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><pre>Stated more generally, given two
identifiers that happen to correspond to DNS domain names, the temptation
thus far has been to seek a solution that emphasizes the nature and design =
of
the DNS protocol.  This needs to be resisted; instead, a solution is needed
that emphasizes the needs of the applications using the identifiers, not
merely what the DNS can offer.</pre></div></blockquote>NEW:<br></div><div c=
lass=3D"gmail_quote"><div><div><br>Historically,
 solutions for identifying relationships between domain names have been=20
based almost exclusively on the DNS namespace and protocol.=C2=A0 While thi=
s=20
basis is often sufficient, the fact that it relies on assumptions=20
stemming from the nature of the DNS makes such solutions unreliable and=20
unnecessarily constrained.=C2=A0 For example, confirming or dismissing a=20
relationship between two domain names based on the existence of a zone=20
cut or common ancestry is often unfounded.</div></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><pre>Currently, the only solu=
tion in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is kept curren=
t
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.</pre></div></blockquote><div>NEW:<b=
r><div><br></div>Currently, the most well known solution in=20
existence is the Public Suffix List (PSL).=C2=A0 The PSL is maintained by a=
=20
Web browser producer and is kept current by volunteers on a best-effort=20
basis.=C2=A0 It contains a list of points in the DNS tree at which=20
registrations take place and is used to identify the boundary between so-ca=
lled &quot;public&quot; names (below which registrations can occur) and the=
 private names (i.e., registered names) below them.<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><pre>  When this list =
is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.</pre></div></blockquote><div><br></div><div>COMMENT: W=
hile the above statement is true, this can be said about any solution--even=
 those produced by this WG.=C2=A0 So I&#39;m not sure this sentence adds an=
ything useful, and I think it should be struck.<br><br></div><div>OLD:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><pr=
e>  It amounts to a third set of semantics imposed upon
the DNS from without, creating unrealistic expectations and eventually
solving the wrong problem.</pre></div></blockquote><div>COMMENT: This sente=
nce is subjective and is (in my opinion) much overstating the problem.=C2=
=A0 See the restatement below.<br><br>NEW:<br><br></div><div>Being the de f=
acto resource, and lacking a more comprehensive, alternative solution for r=
elationship identification, the functionality of the PSL has often been mis=
used to accomplish means beyond its capabilities.=C2=A0 For example, there =
is no way to confirm the relationship between two domain names, only signal=
 that there is or is not a public boundary between the two.<br><br>(OPTIONA=
L: Additionally, there are questions about the scalability, central managem=
ent, and third-party management of the PSL as it currently exists.)<br></di=
v><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><p=
re>In terms of specific use cases: Within the realm of email, there is a
desire to map an arbitrary domain name to the </pre></div></blockquote><div=
><br></div><div>OLD: <br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><pre>registered domain name
somewhere in the tree above it,<br></pre></div></blockquote><div>NEW:<br>or=
ganizational domain name (traditionally in the namespace above it),<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><pre> =
in order to identify a deterministic
location where some sort of statement of policy regarding that domain
name can be found.</pre></div></blockquote><div><br></div><div>OLD: <br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><pre>=
With respect to the web, there is a similar practice
of identifying domains as related as long as they share a common ancestor.<=
/pre></div></blockquote><div>NEW:<br></div><div>With respect to the Web, th=
ere is a similar need to identify relationships between different domains, =
currently accomplished by comparing ancestries.<br><br></div><div>OLD: <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><p=
re>However, there is an additional need for the capability to declare
relationships between arbitrary names.</pre></div></blockquote><div><br></d=
iv><div>NEW:<br></div><div>However, there is also desire to reliably identi=
fy relationships outside of the realm and constraints of the DNS namespace =
tree.<br></div><br></div><div class=3D"gmail_quote">Regards,<br></div><div =
class=3D"gmail_quote">Casey<br></div></div></div></div>

--001a113703b4199a350508b157cf--


From nobody Tue Nov 25 09:12:58 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB631A1F73 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1H9GBCVDfWX for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:12:51 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516AE1A2130 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:12:51 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAPHClaJ014658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <dbound@ietf.org>; Tue, 25 Nov 2014 09:12:50 -0800
Message-ID: <5474B881.5050608@dcrocker.net>
Date: Tue, 25 Nov 2014 09:12:33 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dbound@ietf.org
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
In-Reply-To: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Nov 2014 09:12:51 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/DNtf3z4c2ze_M6bB3gNGuzpxQMk
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:12:54 -0000

The following is based on the original draft of the 'sketch' draft
charter...



> dbound charter
> 
> Various Internet protocols and applications require some mechanism for
> determining whether two Domain Name System (DNS) names are related.  A
> popular example is the need to determine whether example.com
> <http://example.com> and foo.example.com <http://foo.example.com> are
> related; though to humans the answer to this may be obvious, it is

     related; though to humans
     ->
     subject to the same administrative authority.  To humans...


Since this is an example, make it be very specific to a very common and
very obvious case, while avoiding repetition of a key term like related
(since 'related' hasn't been defined yet and could mean many things.)


> difficult to establish this programatically.

I'd suggest changing "it is...programatically" to something like:

   However the DNS does not currently provide the ability to mark these
   sorts of relationships, which makes them impossible to discern with
   simple programming.

> 
> The particular issue is that there is structure imposed by users and by

     is structure -> is [operational / administrative] structure

Since the DNS certainly has structure (hierarchical) it will help to
distinguish what is meant here.  Not sure whether operational or
administrative helps the most.

     users -> organizations

It's a subtle point, but really, DNS admin/ops stuff is better thought
of in terms of groups rather than individuals.


> the domain name registration system that is independent of the
> architecture and protocol upon which the DNS is built.
> 
> In the realm of email, there is a desire to map an arbitrary domain name

Question:  "map"?  Is that really the proper characterization?  Not sure
what to suggest instead, but the term somehow seems odd to me. Perhaps
"connect" or "link" (where the latter invokes a unix-ism.)

     arbitrary domain name -> fully-qualified domain name (FQDN)

> to the registered domain name somewhere in the tree above it, in order

   the registered domain name somewhere in the tree above it,
   ->
   to a portion of the domain name earlier in its hierarchy.  (This is
   sometimes called the "organizational domain".)


> to identify a deterministic location where some sort of statement of
> policy regarding that domain name can be found.  With respect to the

    domain name -> FQDN


> web, there is a similar practice of identifying domains as related as
> long as they share a common ancestor.  However, there is an additional
> need for the capability to declare relationships between arbitrary names.

   arbitrary names
   ->
   arbitrary names, independent of their respective places in the DNS
   hierarchy.


> Previous work such as Author Domain Signing Practices (ADSP; RFC5617)
> and Sender Policy Framework (SPF; RFC7008), and current work such as
> DMARC (draft-kucherawy-dmarc-base), would certainly benefit from having
> this capability.

A blanket statement like this, without explanation, invites challenges,
confusion, and/or flights of pure fantasy.

For example, DMARC contains the organizational domain construct.  SPF
does not.  So I'm not entirely clear how SPF is relevant; I can imagine
all sorts of possibilities, but the reader should not have to guess.

(For reference, if my guess is correct about what is intended with the
SPF reference, it is almost certainly not a viable mechanism, at scale...)

So, it is reasonable to cite previous work that has explicit constructs
that correspond to the work to be done here, although they need to be
referenced explicitly.

For applications which go beyond existing-but-deficient mechanisms, and
create entirely new constructs for the applications, the hypothetical
utility should be offered separately, explicitly and only in very
tentative terms.


> Currently, the only solution in existence is maintained by a web browser
> producer, known as the Public Suffix List.  This list, which is

DMARC also invokes the PSL.


> maintained by volunteers on a best-effort basis, contains a list of
> points in the DNS tree at which registrations take place.  When this
> list is inaccurate, it exposes a deviation with reality that degrades

   with -> from


> service to some and can be exploited by others.
> 
> The DBOUND working group will develop one or more solutions to this
> family of problems.  If possible, a unified solution will be developed. 
> However, the working group may discover that the email, web, and
> equivalence problems require independent solutions, in which case the
> working group will follow that path.  The solutions may or may not
> involve changes to the DNS, such as creation of new resource record
> types; in any case, all such changes will be incremental only.

The above presumes that the only line of plausible differentiation is
application service.  It should allow the possibility that
differentiation could be structural, such as one that is appropriate
between ancestral relationships versus others. Note that this particular
distinction is common to file systems...


> This working group will not seek to amend the consumer protocols
> themselves (i.e., any web or mail standards) without rechartering, and
> only after completion of the base work.  Any such work undertaken in
> parallel will need to be done as individual or independent submissions,
> or in another working group.






-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 25 09:16:58 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5031A86EA for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2kUN_1OVIKw for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:16:49 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C4A1A1F73 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:16:49 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 183308A035 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:16:47 +0000 (UTC)
Date: Tue, 25 Nov 2014 12:16:48 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125171648.GK5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <5474B881.5050608@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5474B881.5050608@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/KvsIG3NWP5if1yNBg1XqeA1mZQk
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:16:50 -0000

On Tue, Nov 25, 2014 at 09:12:33AM -0800, Dave Crocker wrote:
> > The particular issue is that there is structure imposed by users and by
> 
>      is structure -> is [operational / administrative] structure
> 
> Since the DNS certainly has structure (hierarchical) it will help to
> distinguish what is meant here.  Not sure whether operational or
> administrative helps the most.

Neither helps enough.  "Operational" could easily mean DNS operations,
and "administrative" similarly.  Indeed, the SOA record, zone cuts,
and all that _are_ the administrative boundaries in the DNS.

This is the reason I selected "policy" as the term I used as opposed
to those two.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 09:19:34 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6FF1A6F86 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J31LLxFw14gi for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:19:28 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3DB1A1F73 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:19:28 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Nov 2014 09:19:26 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 25 Nov 2014 09:19:26 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Sketch charter
Thread-Index: AQHQCBSr7gqlyJktkEiFvvJMtfoiO5xwiPOAgABZe4CAAAOqAIAA4/KA
Date: Tue, 25 Nov 2014 17:19:25 +0000
Message-ID: <D09A1C9B.738A%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
In-Reply-To: <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499762763_822998"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/3cYbEt4Ab8-TM36_EcFjSCnuMcM
Cc: Scott Kitterman <scott@kitterman.com>, John R Levine <johnl@taugh.com>, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:19:32 -0000

--B_3499762763_822998
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

(Combining three messages in one reply.)

On 11/24/14, 17:43, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

>Better?  (Ignore the two typos, they're already fixed in my repo copy)

This addresses my concerns.  So far.  No doubt I=B9ll have more concerns
later.  But this begins to separate this from being yet another DNS hack
working group (chartering wise).

On 11/24/14, 19:38, "John R Levine" <johnl@taugh.com> wrote:

>>>>Let's not get too metaphysical here.  The names are in the DNS, we=B9re
>>>>trying to represent some of the external semantic
>>>>about how the names are or aren't related to each other.

I think we need to.  But I agree not too much.  I=B9ve seen a lot of
confusion caused by melting the identifier=B9s role and the domain name
system=B9s underpinnings.  I think the a major contribution from this effort
will be to define what is needed to establish the relationship of
identifiers, with knowledge of the DNS but without forcing the solution to
be tied to the structure of the DNS.

After reading the charter, I went back to the mail of a week ago and see
this even more clearly.  E.g., we want to not have to post this kind of
message, where we argue over DNS terms and then excuse the tripping over
DNS administration and policy boundaries.

    http://www.ietf.org/mail-archive/web/dbound/current/msg00173.html

There were other messages skirting the point, there=B9s no =B3smoking gun
message=B2 but it=B9s clear that many of us are still blurring the lines of
the problem being either one of applications or one of DNS.

On 11/25/14, 10:27, "John R Levine" <johnl@taugh.com> wrote:

>>given two identifiers that happen to correspond to DNS domain names,
>given two domain names


I disagree with this.  This is not about domain names (in the eyes of
someone who=B9s spent umpteen years thinking the world revolves around port
53) but about what they represent.  Whether it=B9s a host named in an X.509
Subject Alternate Name or the =8Cauthority=B9 in the Java URL class, or the
sending agent of a mail message, make it clear that it is not about the
domain name system.

Perhaps =B3identifier=B2 conjures up a wider array of naming systems.  Maybe
that=B9s the hang up.  That=B9s why I suggested saying =B3identifiers based on
domain names=B2 and then for the rest of the charter sticking to identifiers.

If we don=B9t do this, we are going to repeat the cycle of stamping out DNS
details (like DNS zone cuts) as new people become engaged in the
discussions.  At this point, those already tuned it will have seen this
discussed, but I know from experience of being a late comer - and seeing
late comers come on board - details like this will return.  At least if it
is in the charter there=B9s a higher chance of dealing with this than if it
is buried in the pre-WG archives.

--B_3499762763_822998
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQUgNsDvKgBkl9wjfzM
J1Ah3OfxYjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjUxNzE5MjNaMA0GCSqGSIb3DQEBAQUABIIBAJBUjWjrQh9/zLgzX6BNqbsfFoa0aA5hANsE
vz/jx1Kkte8bTBgix+z9Ndlr9F/+4k28l01Vh4XbSvT0noJmTx1kAC0dJYpj5nVH6tZOrLsP
nncbiTFlRN7YPGaV6QFzr8sPzVI5+wFkt/XmxGXlH7uYyCrM0nJL/vI+8JvU4Aj08BJRXrNa
/oJZSlk9lxaO5afsJ5QHhyyG5uraJDeNYbJHCFx7uqJ0CxXMrvf0zlE2kXaGXu8+7gqUUNBw
GdTfonhK6RC9D2s/E/Vx55Zctuvcx1zyawCojwiUcOO9mq6xHf+xP7Z6yj6ndvfjsYK5piBN
pArlFrhszPuKZSQqa4E=

--B_3499762763_822998--


From nobody Tue Nov 25 09:23:12 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3E1A871C for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsLZJK1BjM4h for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:22:59 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8EE1A86F5 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:22:41 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAPHMame014846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 09:22:40 -0800
Message-ID: <5474BACF.9030307@dcrocker.net>
Date: Tue, 25 Nov 2014 09:22:23 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>, dbound@ietf.org
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <5474B881.5050608@dcrocker.net> <20141125171648.GK5479@mx1.yitter.info>
In-Reply-To: <20141125171648.GK5479@mx1.yitter.info>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Nov 2014 09:22:40 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/5IsL9ucsPcdZ081XNA1YaYtoznI
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:23:01 -0000

On 11/25/2014 9:16 AM, Andrew Sullivan wrote:
> On Tue, Nov 25, 2014 at 09:12:33AM -0800, Dave Crocker wrote:
>>> The particular issue is that there is structure imposed by users and by
>>
>>      is structure -> is [operational / administrative] structure
>>
>> Since the DNS certainly has structure (hierarchical) it will help to
>> distinguish what is meant here.  Not sure whether operational or
>> administrative helps the most.
> 
> Neither helps enough.  "Operational" could easily mean DNS operations,
> and "administrative" similarly.  Indeed, the SOA record, zone cuts,
> and all that _are_ the administrative boundaries in the DNS.
> 
> This is the reason I selected "policy" as the term I used as opposed
> to those two.


For general discussion in formulating IETF work, the word "policy"
without quite a bit of supporting material is almost never helpful (IMO,
of course) given how vague and often confusing the term is in IETF
discussions.

(I'm not suggesting never using it, but merely never using it without
considerably more clarity and precision.)

The point I intended is that either operational or administrative would
be reasonable; I doubt the distinction is essential at this point of in
the text.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 25 09:29:35 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5531ACEAB for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhAd3fe1oQLv for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:29:33 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EEF1ACEC4 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:29:31 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAPHTPp7015157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 09:29:28 -0800
Message-ID: <5474BC68.6010005@dcrocker.net>
Date: Tue, 25 Nov 2014 09:29:12 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Edward Lewis <edward.lewis@icann.org>, "dbound@ietf.org" <dbound@ietf.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org>
In-Reply-To: <D09A1C9B.738A%edward.lewis@icann.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Nov 2014 09:29:29 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6wY2i_qMmOBRazss1-zMirssB-Y
Cc: Scott Kitterman <scott@kitterman.com>, "Murray S. Kucherawy" <superuser@gmail.com>, John R Levine <johnl@taugh.com>
Subject: [Dbound] identifiers vs. domain names (was Re:  Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:29:34 -0000

On 11/25/2014 9:19 AM, Edward Lewis wrote:
> On 11/24/14, 19:38, "John R Levine" <johnl@taugh.com> wrote:
> 
>>>>> Let's not get too metaphysical here.  The names are in the DNS, weąre
>>>>> trying to represent some of the external semantic
>>>>> about how the names are or aren't related to each other.
> 
> I think we need to.  But I agree not too much.  Iąve seen a lot of
> confusion caused by melting the identifierąs role and the domain name
> systemąs underpinnings.  I think the a major contribution from this effort
> will be to define what is needed to establish the relationship of
> identifiers, with knowledge of the DNS but without forcing the solution to
> be tied to the structure of the DNS.
...
> On 11/25/14, 10:27, "John R Levine" <johnl@taugh.com> wrote:
> 
>>> given two identifiers that happen to correspond to DNS domain names,
>> given two domain names
> 
> 
> I disagree with this.  This is not about domain names (in the eyes of
> someone whoąs spent umpteen years thinking the world revolves around port
> 53) but about what they represent. 



This is a spectacularly basic point of distinction, for the work being
done here.

It is one thing to revise/augment the DNS and quite another to define an
overlay (identifier) mechanism that happens to use the DNS.

To insist on the abstraction 'identifier' is to insist on an overlay model.

We should get agreement about the nature of the work to be done.

If this is about an overlay identifier mechanism, where is this
described.  We need to understand the identifier model because we can
consider enhancing 'relationships' in it.

If this is about enhancing the DNS itself, then we should say domain
name and not identifier or some other abstraction.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 25 09:30:19 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00F1ACEC0 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njt3844lorQO for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:30:14 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465CB1A8722 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:30:14 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex7so9913290wid.3 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Qu9ECzgHpsa5Fj1idEJN7WM02e3hIOT4DuSbSQZGENg=; b=heFMA9idpoJgnzELg9+R5h678d0Wt9bebfvUMwvJm/0oS7oy208KiSKp7Argw/S0OQ ZI+d0Hb6+wN+Jr37BbUgJJGr282cuX55LkbYgzs9qHRxodErac01ozA4igSGkjML/T9g q6vfyatGbgj5YyWovgC75eWEJ8GKWEDHlfMxXULipGaN5u/EmRtH3AQbi5zB2zkj8zXG GIpZvnE7vJTOzsObhc+gEiG1n4SZOl3cvpVXQ5VyIzLdXmi8zrLAoAqvJ84O0dN0CKBt Z0ghENaTWJl15O0f4J0hIB02UD6jC/dUSnzdPbAWHtsu1wW2PE2RPYJA42BxEHHU9A7Y SncA==
MIME-Version: 1.0
X-Received: by 10.180.75.199 with SMTP id e7mr33973934wiw.21.1416936612986; Tue, 25 Nov 2014 09:30:12 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Tue, 25 Nov 2014 09:30:12 -0800 (PST)
In-Reply-To: <5474BACF.9030307@dcrocker.net>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <5474B881.5050608@dcrocker.net> <20141125171648.GK5479@mx1.yitter.info> <5474BACF.9030307@dcrocker.net>
Date: Tue, 25 Nov 2014 09:30:12 -0800
Message-ID: <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=f46d043895777c83800508b24314
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TtD20e_254psBNGaKc3psurVPgU
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:30:17 -0000

--f46d043895777c83800508b24314
Content-Type: text/plain; charset=UTF-8

Here's where we are right now.  It folds in all suggestions, but that
includes John's last one with which Ed is disagreeing.

I guess we should hear from others on the use of "identifiers" versus
"domain names".  Anyone else care to comment?

Ed or John, care to propose some compromise text?

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifiers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether example.com
and foo.example.com are subject to the same administrative authority.
To humans, the answer to this may be obvious.  However, the DNS does not
currently provide the ability to mark these sorts of relationships, which
makes them impossible to discern with simple programming.  For example,
the right answer is not always "compare the rightmost two labels".

The particular issue is that there is policy structure imposed by
organizations and by the domain name registration system that is independent
of the architecture and protocol upon which the DNS is built.  Historically,
solutions for identifying relationships between domain names have been based
almost exclusively on the DNS namespace and protocol.  While this basis is
often sufficient, the fact that it relies on assumptions stemming from the
nature of the DNS makes such solutions unreliable and unnecessarily
constrained.  For example, confirming or dismissing a relationship between
two domain names based on the existence of a zone cut or common ancestry is
often unfounded.

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the DNS tree at which registrations take place and is used to identify
the boundary between so-called "public" names (below which registrations
can occur) and the private names (i.e., registered names) below them.
When this list is inaccurate, it exposes a deviation from reality that
degrades service to some and can be exploited by others.  Being the de
facto resource, and lacking a more comprehensive, alternative solution for
relationship identification, the functionality of the PSL has often been
misused to accomplish means beyond its capabilities.  For example, there
is no way to confirm the relationship between two domain names, only
signal that there is or is not a public boundary between the two.
Additionally, there are questions about the scalability, central management,
and third-party management of the PSL as it currently exists.

In terms of specific use cases: Within the realm of email, there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (traditionally in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that domain name can be found.  With respect to the
web, there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the DNS namespace tree.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, equivalence, and
possibly other problems require independent solutions, in which case the
working group will follow that path.  The solutions may or may not involve
changes to the DNS, such as creation of new resource record types; in any
case, all such changes will be incremental only.

This working group will not seek to amend the consuming protocols themselves
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
eeed to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD



On Tue, Nov 25, 2014 at 9:22 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 11/25/2014 9:16 AM, Andrew Sullivan wrote:
> > On Tue, Nov 25, 2014 at 09:12:33AM -0800, Dave Crocker wrote:
> >>> The particular issue is that there is structure imposed by users and by
> >>
> >>      is structure -> is [operational / administrative] structure
> >>
> >> Since the DNS certainly has structure (hierarchical) it will help to
> >> distinguish what is meant here.  Not sure whether operational or
> >> administrative helps the most.
> >
> > Neither helps enough.  "Operational" could easily mean DNS operations,
> > and "administrative" similarly.  Indeed, the SOA record, zone cuts,
> > and all that _are_ the administrative boundaries in the DNS.
> >
> > This is the reason I selected "policy" as the term I used as opposed
> > to those two.
>
>
> For general discussion in formulating IETF work, the word "policy"
> without quite a bit of supporting material is almost never helpful (IMO,
> of course) given how vague and often confusing the term is in IETF
> discussions.
>
> (I'm not suggesting never using it, but merely never using it without
> considerably more clarity and precision.)
>
> The point I intended is that either operational or administrative would
> be reasonable; I doubt the distinction is essential at this point of in
> the text.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>

--f46d043895777c83800508b24314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Here&#39;s where we are right now.=C2=A0 It folds in =
all suggestions, but that includes John&#39;s last one with which Ed is dis=
agreeing.<br><br>I guess we should hear from others on the use of &quot;ide=
ntifiers&quot; versus &quot;domain names&quot;.=C2=A0 Anyone else care to c=
omment?<br><br></div>Ed or John, care to propose some compromise text?<br><=
div><br><pre>dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifiers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether <a href=3D=
"http://example.com">example.com</a>
and <a href=3D"http://foo.example.com">foo.example.com</a> are subject to t=
he same administrative authority.
To humans, the answer to this may be obvious.  However, the DNS does not
currently provide the ability to mark these sorts of relationships, which
makes them impossible to discern with simple programming.  For example,
the right answer is not always &quot;compare the rightmost two labels&quot;=
.

The particular issue is that there is policy structure imposed by
organizations and by the domain name registration system that is independen=
t
of the architecture and protocol upon which the DNS is built.  Historically=
,
solutions for identifying relationships between domain names have been base=
d
almost exclusively on the DNS namespace and protocol.  While this basis is
often sufficient, the fact that it relies on assumptions stemming from the
nature of the DNS makes such solutions unreliable and unnecessarily
constrained.  For example, confirming or dismissing a relationship between
two domain names based on the existence of a zone cut or common ancestry is
often unfounded.

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the DNS tree at which registrations take place and is used to identify
the boundary between so-called &quot;public&quot; names (below which regist=
rations
can occur) and the private names (i.e., registered names) below them.
When this list is inaccurate, it exposes a deviation from reality that
degrades service to some and can be exploited by others.  Being the de
facto resource, and lacking a more comprehensive, alternative solution for
relationship identification, the functionality of the PSL has often been
misused to accomplish means beyond its capabilities.  For example, there
is no way to confirm the relationship between two domain names, only
signal that there is or is not a public boundary between the two.
Additionally, there are questions about the scalability, central management=
,
and third-party management of the PSL as it currently exists.

In terms of specific use cases: Within the realm of email, there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (traditionally in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that domain name can be found.  With respect to the
web, there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the DNS namespace tree.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, equivalence, and
possibly other problems require independent solutions, in which case the
working group will follow that path.  The solutions may or may not involve
changes to the DNS, such as creation of new resource record types; in any
case, all such changes will be incremental only.

This working group will not seek to amend the consuming protocols themselve=
s
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
eeed to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD
</pre><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Tue, Nov 25, 2014 at 9:22 AM, Dave Crocker <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocker.net</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/25=
/2014 9:16 AM, Andrew Sullivan wrote:<br>
&gt; On Tue, Nov 25, 2014 at 09:12:33AM -0800, Dave Crocker wrote:<br>
&gt;&gt;&gt; The particular issue is that there is structure imposed by use=
rs and by<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 is structure -&gt; is [operational / administr=
ative] structure<br>
&gt;&gt;<br>
&gt;&gt; Since the DNS certainly has structure (hierarchical) it will help =
to<br>
&gt;&gt; distinguish what is meant here.=C2=A0 Not sure whether operational=
 or<br>
&gt;&gt; administrative helps the most.<br>
&gt;<br>
&gt; Neither helps enough.=C2=A0 &quot;Operational&quot; could easily mean =
DNS operations,<br>
&gt; and &quot;administrative&quot; similarly.=C2=A0 Indeed, the SOA record=
, zone cuts,<br>
&gt; and all that _are_ the administrative boundaries in the DNS.<br>
&gt;<br>
&gt; This is the reason I selected &quot;policy&quot; as the term I used as=
 opposed<br>
&gt; to those two.<br>
<br>
<br>
</span>For general discussion in formulating IETF work, the word &quot;poli=
cy&quot;<br>
without quite a bit of supporting material is almost never helpful (IMO,<br=
>
of course) given how vague and often confusing the term is in IETF<br>
discussions.<br>
<br>
(I&#39;m not suggesting never using it, but merely never using it without<b=
r>
considerably more clarity and precision.)<br>
<br>
The point I intended is that either operational or administrative would<br>
be reasonable; I doubt the distinction is essential at this point of in<br>
the text.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
d/<br>
</font></span><span class=3D"im HOEnZb"><br>
<br>
--<br>
Dave Crocker<br>
Brandenburg InternetWorking<br>
<a href=3D"http://bbiw.net" target=3D"_blank">bbiw.net</a><br>
<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________=
___________________<br>
Dbound mailing list<br>
<a href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br>
</div></div></blockquote></div><br></div>

--f46d043895777c83800508b24314--


From nobody Tue Nov 25 09:39:15 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10A1A86E7 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huuJT5EVd3yM for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:39:11 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332481A0368 for <dbound@ietf.org>; Tue, 25 Nov 2014 09:39:06 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8AD298A035 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:39:04 +0000 (UTC)
Date: Tue, 25 Nov 2014 12:39:05 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125173904.GM5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <5474B881.5050608@dcrocker.net> <20141125171648.GK5479@mx1.yitter.info> <5474BACF.9030307@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5474BACF.9030307@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/z2sqL2evTZXZE5hzXyRl8uSU8qk
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:39:12 -0000

On Tue, Nov 25, 2014 at 09:22:23AM -0800, Dave Crocker wrote:
> For general discussion in formulating IETF work, the word "policy"
> without quite a bit of supporting material is almost never helpful (IMO,
> of course) given how vague and often confusing the term is in IETF
> discussions.

This is probably true.  But the point is that the thing we're talking
about is operational policy about the name in the DNS, and _not_
operation of the name in the DNS.  I don't have a better word that
"policy", though I agree with you that it has problematic baggage.  

> The point I intended is that either operational or administrative would
> be reasonable

The point I'm trying to make, however, is that those words are both
going to cause confusion, because people who come at this with a DNS
background will immediately associate each of them with the associated
activity of the domain itself (i.e. administration or operation of the
DNS bits of that name).  That's _precisely_ the thing we're not
talking about.  When I was first trying out these ideas, I used both
"operational" and "administrative" in early discussions, and fell into
this very problem with my interlocutors; so I'm not worrying about
something theoretical.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 09:46:12 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AFE1A8729 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhBGxjmEzzdO for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 09:46:07 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6783C1A872A for <dbound@ietf.org>; Tue, 25 Nov 2014 09:46:07 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D8F6A8A035 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:46:05 +0000 (UTC)
Date: Tue, 25 Nov 2014 12:46:06 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125174605.GN5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D09A1C9B.738A%edward.lewis@icann.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/SZnH9Bwq_djGkCmTRrw0gXrxov8
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 17:46:08 -0000

On Tue, Nov 25, 2014 at 05:19:25PM +0000, Edward Lewis wrote:

> I disagree with this.  This is not about domain names (in the eyes of
> someone whoÂąs spent umpteen years thinking the world revolves around port
> 53) but about what they represent.  Whether itÂąs a host named in an X.509
> Subject Alternate Name or the ÂŚauthorityÂą in the Java URL class, or the
> sending agent of a mail message, make it clear that it is not about the
> domain name system.

It is not about the DNS, correct, but it is about domain names.  That
is, the work is not intended to apply to other kinds of identifiers
such as complete email addresses, NetBIOS names, mDNS names, and so on.

I think what you need is something like this:

    For the purposes of this work, domain names are approached as
    identifiers used in other services, and not as DNS names in
    themselves.  The working group is not chartered to do any work on
    management of the DNS itself.  The structure of the DNS and the
    administrative boundaries in the DNS are entirely out of scope for
    the working group.

Then we can use "domain names"; I think John is right that we are in
fact working on identifiers that are always domain names, and that it
is therefore wrong not to call them by that name.  But you're quite
right that we need to call out quite clearly that fact, or we'll spend
half our time explaining why zone cuts don't help.  (No matter what we
do, we'll probably have to do that explanation several times anyway.)

> Perhaps ³identifier² conjures up a wider array of naming systems.  Maybe
> thatÂąs the hang up.  ThatÂąs why I suggested saying Âłidentifiers based on
> domain names² and then for the rest of the charter sticking to identifiers.

"Identifiers" is clearly too broad, IMO.

A
-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 10:20:00 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C1D1A6F7F for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJUXKN1wea2N for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:19:25 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7DE31A6FEE for <dbound@ietf.org>; Tue, 25 Nov 2014 10:18:41 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id l13so5865719iga.9 for <dbound@ietf.org>; Tue, 25 Nov 2014 10:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b1QLXonUJ5fqdlANR5in2raB8CJ0OnevNpygIxYKe9c=; b=bCvdkGhiYwH/iyOpw90lPPF8w4duuuUX6qMEJozra8avrFU9bIb2X2laV2fPSzqn9v JiJWeuR2hiMoINmEs3bUY5APsFRA7jP/7G+NsjxPJWnrH9FmuiD0UU4+vVNLFegog5Qg hBwIFTDglWNe+wKvfxWPxL2riZxbh7JE9BWmY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b1QLXonUJ5fqdlANR5in2raB8CJ0OnevNpygIxYKe9c=; b=TSpbyRGlayJajNdZYvJCpK6zFg/pH75OdTTJE3cf33zjBO4H6yyUTLRcP+PNAXKDZa w0AfPSa5sBgPeKh/ki1H1RFH9zOwoMht+bg+9wKpz4+4kX2LnV0xXdeXCVdD8XtatW7v UxNESWqOKhhYVSLSgtwe1ayOZAsIZmOSV3PVLHa5Xj1L94bN0KLsYcrR+s4fRaBCe5Aa YsjPcE8KO79fnWnufknNfkOC2xZCRi/Y23P+iU1cP4VKFK15fX08c+VoK/KYh5OQwyw0 tf8A+hpqhyviLsCRGaIRt7mKEIe1SMTNnuJUMKUhAnscM6VPyLZuwzP9wuOTNEDgUyQG agWg==
X-Gm-Message-State: ALoCoQkoycZMS8XRfFJtQ5zShNiAnp90IlCdvhgHrBIBjWiftsE8n5VX0SqMQ8yKvcBMh1KXkVDK
MIME-Version: 1.0
X-Received: by 10.50.142.33 with SMTP id rt1mr18799285igb.12.1416939519359; Tue, 25 Nov 2014 10:18:39 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 25 Nov 2014 10:18:39 -0800 (PST)
In-Reply-To: <20141125174605.GN5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <20141125174605.GN5479@mx1.yitter.info>
Date: Tue, 25 Nov 2014 13:18:39 -0500
Message-ID: <CAEKtLiQiBXaDgT5xZzjaUmMi=R4xjpk0L9RJbGWbD1ySVDgPYA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary=001a1130d17ab87e820508b2f070
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Coa0BzZDFTWn5JJI_5mbEPGWs0Q
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 18:19:26 -0000

--001a1130d17ab87e820508b2f070
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 25, 2014 at 12:46 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

>
> It is not about the DNS, correct, but it is about domain names.


Agree.


>     ...



> The structure of the DNS and the
>     administrative boundaries in the DNS are entirely out of scope for
>     the working group.
>

Here I disagree.  What good would it do us to move this out of scope?
There is a difference between relying exclusively on the DNS structure and
administrative boundaries for solving the problem and not being constrained
by them for the purposes of solving the problem.


> "Identifiers" is clearly too broad, IMO.
>

Agree.

Casey

--001a1130d17ab87e820508b2f070
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 12:46 PM, Andrew Sullivan <span di=
r=3D"ltr">&lt;<a href=3D"mailto:ajs@anvilwalrusden.com" target=3D"_blank">a=
js@anvilwalrusden.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><=
br>
</span>It is not about the DNS, correct, but it is about domain names.</blo=
ckquote><div><br></div><div>Agree.<br>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
=C2=A0 =C2=A0 ... </blockquote><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">The structure of the DNS and the<br>
=C2=A0 =C2=A0 administrative boundaries in the DNS are entirely out of scop=
e for<br>
=C2=A0 =C2=A0 the working group.<br></blockquote><div><br></div><div>Here I=
 disagree.=C2=A0 What good would it do us to move this out of scope?=C2=A0 =
There is a difference between relying exclusively on the DNS structure and =
administrative boundaries for solving the problem and not being constrained=
 by them for the purposes of solving the problem.<br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
&quot;Identifiers&quot; is clearly too broad, IMO.<br></blockquote><div><br=
></div><div class=3D"h5">Agree.<br><br>Casey<br></div></div></div></div>

--001a1130d17ab87e820508b2f070--


From nobody Tue Nov 25 10:22:09 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3E1A0264 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Ef4VkYXp7L for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:21:13 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBC21A0262 for <dbound@ietf.org>; Tue, 25 Nov 2014 10:21:13 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DD8388A035 for <dbound@ietf.org>; Tue, 25 Nov 2014 18:21:11 +0000 (UTC)
Date: Tue, 25 Nov 2014 13:21:13 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125182112.GO5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <20141125174605.GN5479@mx1.yitter.info> <CAEKtLiQiBXaDgT5xZzjaUmMi=R4xjpk0L9RJbGWbD1ySVDgPYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEKtLiQiBXaDgT5xZzjaUmMi=R4xjpk0L9RJbGWbD1ySVDgPYA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oicxtidccWFVQYm4hzsegzREEZw
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 18:21:16 -0000

On Tue, Nov 25, 2014 at 01:18:39PM -0500, Casey Deccio wrote:
> > The structure of the DNS and the
> >     administrative boundaries in the DNS are entirely out of scope for
> >     the working group.
> >
> 
> Here I disagree.  What good would it do us to move this out of scope?

There already is a WG that has that in scope, and I would expect the
IESG to be reluctant to charter two WGs with the same
responsibilities.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 10:49:45 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566291A873F for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EWEwhkKj1tO for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:48:32 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEC41A877A for <dbound@ietf.org>; Tue, 25 Nov 2014 10:48:32 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Nov 2014 10:48:30 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 25 Nov 2014 10:48:30 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: identifiers vs. domain names (was Re: [Dbound] Sketch charter)
Thread-Index: AQHQCNVhgHFeaevOyEqHW7iwhaczo5xx4WuA
Date: Tue, 25 Nov 2014 18:48:29 +0000
Message-ID: <D09A3686.73B0%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net>
In-Reply-To: <5474BC68.6010005@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499768107_1147804"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/SdXgoc291iBXyfSdTuURV6GtiKk
Cc: "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 18:48:34 -0000

--B_3499768107_1147804
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



On 11/25/14, 12:29, "Dave Crocker" <dhc@dcrocker.net> wrote:



>If this is about an overlay identifier mechanism, where is this
>described.  We need to understand the identifier model because we can
>consider enhancing 'relationships' in it.

My intent is not to create an overlay identifier mechanism, but rather...

>
>If this is about enhancing the DNS itself, then we should say domain
>name and not identifier or some other abstraction.

...Avoid the notion that we are enhancing the DNS.

That=E2=80=99s why I=E2=80=99ve used =E2=80=9Cidentifiers based on domain names=E2=80=9D.

I can=E2=80=99t call them identifiers syntactically the same as domain names
because I doubt (correct me if I am wrong) that the X.509 Subject
Alternate Name field would encode =E2=80=9Cwww.example.com=E2=80=9D as characters in AS=
N.1
and not in the DNS wire format (like - 3www-7example3com0).

I realize that to most people =E2=80=9Chost.example.com=E2=80=9D is what is sent in dig=
 to
get an address or in ssh to login to a host.  But there is a recognized
difference between 127.0.0.1 and 1.0.0.127.in-addr.arpa.  In dig and ssh,
the two would be treated differently (yes, there is dig -x).

My goal is not to dredge up an identifier system.  My goal is bury the
notion that we are enhancing the DNS.  If there=E2=80=99s another way to do this,
I=E2=80=99m open to suggestion.  (I mean, another apart from mentioning in the
intro "identifiers based on domain names.=E2=80=9D

The fact is that we have a defacto identifier overlay abstraction in place
- ever since URLs included in the =E2=80=9Cprinted=E2=80=9D form of DNS.  No need to
define it, just dance around it.

--B_3499768107_1147804
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSTeTi4QyCT/nLUXjCe
bES6G1O8pDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjUxODQ4MjdaMA0GCSqGSIb3DQEBAQUABIIBAHRetdAlgbUIEFSj7PwZzois3blZPI4eMhat
3gRaBRhKoIIiH1gSBU+4cUyEWzk1v1ZLYkurLw0F/66jINjMi+Wg39ZaVgcOkwZXuCfgJsvc
MYaVPKMTXMrfx4/u6L7Ar2yggkZg+Tlo57P89LfY6sg565Y7yrJdEndU9rEFfrC7b16HhML+
1VvR6L3+FzeqFfSu8E6NgtUwoP+bNXt5SJPXoenRTP83BOtiL+dLUL6wSOW0gDNxOP8cIcjs
nFM55MxEox6OsvDKXFOl//bP3WPiaFTmCjzwokqbX3D3Tw7sMlq8G35r1vU31p5nRuJnFokT
DL+GgFgR+/MlPS6zEYA=

--B_3499768107_1147804--


From nobody Tue Nov 25 10:56:34 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D471ACECF for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLzh5HreJ311 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:55:27 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789381A1A67 for <dbound@ietf.org>; Tue, 25 Nov 2014 10:55:27 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id r20so12892118wiv.4 for <dbound@ietf.org>; Tue, 25 Nov 2014 10:55:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w2+UtoLE8hBVNlCn1M3Vuo6JfHLyQPZm1tOV7XULkcg=; b=NIkwijWdZPfvh7ahCJJ/aGfbflY4yoxGDi9Gzdzj9PrQ9RwjmKJmbrB/ln6sRJL+u7 gPp5ITCRsB/Gv1791x83YVe0xmj626jbyYcLWqeUAzGYkVOFZJ6Om6TLpUnA96h/pr6M l6Yfx14esPKp6nIuwWQFbpTsQSYQPwpzQCCBmxkrTSFQdlXp3wIEyK4fqY0CE/XTjO/e haad2vGZj0gm2SbFDPmVfvwnQr9W3G/IuaUyPm32l0EKxBMgGjvpCv9Xt4vdOaXUAv4v wJU10hIz+z6of/bLJgZay7F5ZZEHtNY9QSXIOTcTJzxsGvr3SQgDg0u6VY3z2w0uWLX+ 8MGA==
MIME-Version: 1.0
X-Received: by 10.180.91.36 with SMTP id cb4mr25096234wib.30.1416941725974; Tue, 25 Nov 2014 10:55:25 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Tue, 25 Nov 2014 10:55:25 -0800 (PST)
In-Reply-To: <D09A3686.73B0%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org>
Date: Tue, 25 Nov 2014 10:55:25 -0800
Message-ID: <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary=f46d043d67113e9e770508b3743d
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TU-rb9tNbcid1OvlUridXRFGnDc
Cc: "dcrocker@bbiw.net" <dcrocker@bbiw.net>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 18:55:29 -0000

--f46d043d67113e9e770508b3743d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 25, 2014 at 10:48 AM, Edward Lewis <edward.lewis@icann.org>
wrote:

> My goal is not to dredge up an identifier system.  My goal is bury the
> notion that we are enhancing the DNS.  If there=E2=80=99s another way to =
do this,
> I=E2=80=99m open to suggestion.  (I mean, another apart from mentioning i=
n the
> intro "identifiers based on domain names.=E2=80=9D
>
> The fact is that we have a defacto identifier overlay abstraction in plac=
e
> - ever since URLs included in the =E2=80=9Cprinted=E2=80=9D form of DNS. =
 No need to
> define it, just dance around it.
>

Does Andrew's proposed paragraph deal with this concern?

--f46d043d67113e9e770508b3743d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 10:48 AM, Edward Lewis <span dir=
=3D"ltr">&lt;<a href=3D"mailto:edward.lewis@icann.org" target=3D"_blank">ed=
ward.lewis@icann.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My goal is not to d=
redge up an identifier system.=C2=A0 My goal is bury the<br>
notion that we are enhancing the DNS.=C2=A0 If there=E2=80=99s another way =
to do this,<br>
I=E2=80=99m open to suggestion.=C2=A0 (I mean, another apart from mentionin=
g in the<br>
intro &quot;identifiers based on domain names.=E2=80=9D<br>
<br>
The fact is that we have a defacto identifier overlay abstraction in place<=
br>
- ever since URLs included in the =E2=80=9Cprinted=E2=80=9D form of DNS.=C2=
=A0 No need to<br>
define it, just dance around it.<br></blockquote><div><br></div><div>Does A=
ndrew&#39;s proposed paragraph deal with this concern? <br></div></div></di=
v></div>

--f46d043d67113e9e770508b3743d--


From nobody Tue Nov 25 10:58:06 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7C61A6F7D for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnEintYO6KHj for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 10:56:48 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC321ACED7 for <dbound@ietf.org>; Tue, 25 Nov 2014 10:56:47 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Nov 2014 10:56:46 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 25 Nov 2014 10:56:46 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Sketch charter
Thread-Index: AQHQCBSr7gqlyJktkEiFvvJMtfoiO5xyG/OAgAABMACAAAGPgIAAAi8A///EVoA=
Date: Tue, 25 Nov 2014 18:56:46 +0000
Message-ID: <D09A398F.73B3%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <5474B881.5050608@dcrocker.net> <20141125171648.GK5479@mx1.yitter.info> <5474BACF.9030307@dcrocker.net> <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com>
In-Reply-To: <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499768599_1134686"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Dj3CxZzj1hFJT0VHV0Rc8Y2GIK4
Cc: "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 18:56:49 -0000

--B_3499768599_1134686
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 11/25/14, 12:30, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

>Ed or John, care to propose some compromise text?

I=E2=80=99ve done enough list damage for this week.  I=E2=80=99ll wait until we get mor=
e
opinions. ;)

It=E2=80=99s true that the work =E2=80=9Cidentifiers" is too broad given the applicatio=
n
contexts being considered.  While =E2=80=9Cidentifiers based on domain names=E2=80=9D i=
s
the most accurate I can think of, I can see why it isn=E2=80=99t =E2=80=9Cjust right=E2=80=9D

But this is about domain names either for reasons I put into a reply to
Dave Crocker.  The URL doesn=E2=80=99t have what is DNS-wise a domain name as it
appears in the DNS system (in DNS parlance it=E2=80=99s zone file form vs. on the
wire).  The operations done in DNS code on domain names don=E2=80=99t transfer to
operations on zone file forms of names.  I know =E2=80=93 I=E2=80=99ve code in the area=
.
E.g., sorting names (as is done in DNSSEC) has to be done in wire format
and not in zone file form.

I=E2=80=99m getting too esoteric.  That=E2=80=99s why I need to stop and hear other
opinions.  I=E2=80=99ve been viewing the world through port 53 way too long.

--B_3499768599_1134686
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRu3Ri+Fly1kebJpcJ7
1OiAyzR4ijAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjUxODU2MzlaMA0GCSqGSIb3DQEBAQUABIIBAHG8Quw1oPZIC4uvJnEEOaCaXz9rrEA63Yng
5B5s1kpzMTB3WMOPgHYTK2NiP3OnN47n+i3Rhm/Gg09hI8IOKv3Hk/6xUWeYRmiYo7cJ4A3B
W5r2/u0sSNw6ilFU6UggFkKVn3PPTgRAb1GMNhJSu1dSYFOxhxD8w8b5P5hBkF8yCwx8sIrD
kh6hMuGKw4/n/l8Pf07LiRgrZtvRok/65/BIfFJsFI04hbWjwxUFAYXtLarjw8ycCqcjpAFJ
wfYlLi/tuKSfWVee/OFnfKyhPTSYKKRSxh21V9QTCplJyYTAPPGkVmxokRaqnGvLOrc8S1nP
dgqxrE/7Ylo8E7sMeA8=

--B_3499768599_1134686--


From nobody Tue Nov 25 11:03:57 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145161ACF03 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 11:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jLZvb0wW7VR for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 11:02:51 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F201ACEFC for <dbound@ietf.org>; Tue, 25 Nov 2014 11:02:42 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Nov 2014 11:02:41 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 25 Nov 2014 11:02:41 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
Thread-Index: AQHQCOFuocShnNveAUSxF0dwJFLekpxx5UUA
Date: Tue, 25 Nov 2014 19:02:41 +0000
Message-ID: <D09A3B3B.73B8%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org> <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com>
In-Reply-To: <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499768954_1164335"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/TYrgByPyS2N-WsI90Pi-Vbep6Oc
Cc: "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 19:02:53 -0000

--B_3499768954_1164335
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Yeah, I=E2=80=99m more in line with Andrew=E2=80=99s tack than Casey=E2=80=99s.

Here I go again=E2=80=A6.I=E2=80=99m came to this group thinking this might be about th=
e
DNS.  I came from the perspective that it was about zone cuts (evidenced
in my comments on Casey=E2=80=99s pre-IETF91 problem statement).  After the
discussion during IETF 91 I see the problem as entirely external to the
DNS as a system.  It=E2=80=99s about how domain names are manipulated by
applications.  Particularly manipulation of domain names - not general
identifiers.  Given that I agree with Andrew=E2=80=99s paragraph and disagree wit=
h
Casey=E2=80=99s disagreement.

The paragraph being:
On 11/25/14, 12:46, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
>    For the purposes of this work, domain names are approached as
>    identifiers used in other services, and not as DNS names in
>    themselves.  The working group is not chartered to do any work on
>    management of the DNS itself.  The structure of the DNS and the
>    administrative boundaries in the DNS are entirely out of scope for
>    the working group.


On 11/25/14, 13:55, "Murray S. Kucherawy" <superuser@gmail.com> wrote:


>On Tue, Nov 25, 2014 at 10:48 AM, Edward Lewis <edward.lewis@icann.org>
>wrote:
>
>My goal is not to dredge up an identifier system.  My goal is bury the
>notion that we are enhancing the DNS.  If there=E2=80=99s another way to do this=
,
>I=E2=80=99m open to suggestion.  (I mean, another apart from mentioning in the
>intro "identifiers based on domain names.=E2=80=9D
>
>The fact is that we have a defacto identifier overlay abstraction in place
>- ever since URLs included in the =E2=80=9Cprinted=E2=80=9D form of DNS.  No need to
>define it, just dance around it.
>
>
>
>Does Andrew's proposed paragraph deal with this concern?=20

--B_3499768954_1164335
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSHYCzlDIKtjeYHyj71
1cbwQ60f1DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjUxOTAyMzRaMA0GCSqGSIb3DQEBAQUABIIBAHhskN2S/KjHs5QePEuwxsKuNC7hZEebHaWL
53mAgFf/dPu7MeV9FjqVSeWr7x3j6X3Y58cS8lN82+TL+TJJ8fvu1Eq+Op6f2K9uXxxmtnhF
1TiSBUFYkM/MPGiu1e2bS7oGUa6E507b7fiMGTA0mUP0aDJDp3jldlRcU6s22eOSXYD8QEFx
JE25Huj3CmyOpQiu1Fqb9RZdxvag1cAJhvJnNuDhoUHftwv4ufmDca1B207Ksy4hCRDG7XcF
IMC5nHnevc67hskv9YmHqs0khfh65/njcRr+4098x+l9InHRJkbhJZBLL7gCKjiPe7MX6sR1
WWcsW9yOYxDCrewmp0k=

--B_3499768954_1164335--


From nobody Tue Nov 25 12:26:17 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FB01A8852 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXR0pbiiEBLN for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:24:29 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFB51A7005 for <dbound@ietf.org>; Tue, 25 Nov 2014 12:24:28 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id rl12so1322848iec.30 for <dbound@ietf.org>; Tue, 25 Nov 2014 12:24:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kF7pBxi5KCVShqcsCknBVB1Sie7nljPrEmbUckdWq/E=; b=XnXnFMdSlkbNHcr2inxTkH53Xa8DyXCHkuiCuCyIE1zMQhAuM0NHqpb3E3zRtUgpOU EXE3G64b2fDyBNU+/Ri6OtjqRkQfA4ApsyBSUTLEfHQGzu4Qi4iZWQyhgsbTZVbBdKS7 jmBbQTgbmMmOI2+K38MEs3GVg9zBRbxDfC5aI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kF7pBxi5KCVShqcsCknBVB1Sie7nljPrEmbUckdWq/E=; b=XtiTA7RZLF3zACJokAYlJy0PsqGHUUzlF/8lUP2l3cmKPn11DAeswMxtlJxL9fUAiT cvdkXwvlI8u/GG5JFg64iCwBXZhd2dR4XOwSiXNZstB1urlQfj9h8R4PeLvT3aZM1u0X 9n0OZVew8tq3nsm7ooI0JuxDM/Qj+eg+Fdj0Qduoe6YLCCACubmG6Z6vDIp6uaCgGJ0/ rHA0G6nf8i0z9JGxUGUbpETvRVweWQVPiQX3zyQa5TgqPAAv9jRS/6guL4eF0LBXAl5+ BQa9dWvTX83F0SFiIXt3YNRseFQBWeAEyFytBD+/Y9yxFICDaqs56ABJRx21IDQmpZ/1 kKnA==
X-Gm-Message-State: ALoCoQlNInwcMzszUsrbIZI6rZIXT3Xe54K3XkINz2LuIuAWQnWyjd5T7LUV8OpRjLOuDNQHmeiP
MIME-Version: 1.0
X-Received: by 10.107.129.223 with SMTP id l92mr25762354ioi.18.1416947067715;  Tue, 25 Nov 2014 12:24:27 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 25 Nov 2014 12:24:27 -0800 (PST)
In-Reply-To: <20141125182112.GO5479@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <20141125174605.GN5479@mx1.yitter.info> <CAEKtLiQiBXaDgT5xZzjaUmMi=R4xjpk0L9RJbGWbD1ySVDgPYA@mail.gmail.com> <20141125182112.GO5479@mx1.yitter.info>
Date: Tue, 25 Nov 2014 15:24:27 -0500
Message-ID: <CAEKtLiQG3Shhy0H=MASsvWzYUNvfiiYOvGaP=m07x7HfQobKwA@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary=001a113ecf46a31a810508b4b2f9
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/KlDoWzOKcx1ZNCPysW3sPmBQiZ8
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 20:24:30 -0000

--001a113ecf46a31a810508b4b2f9
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 25, 2014 at 1:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

> On Tue, Nov 25, 2014 at 01:18:39PM -0500, Casey Deccio wrote:
> > > The structure of the DNS and the
> > >     administrative boundaries in the DNS are entirely out of scope for
> > >     the working group.
> > >
> >
> > Here I disagree.  What good would it do us to move this out of scope?
>
> There already is a WG that has that in scope, and I would expect the
> IESG to be reluctant to charter two WGs with the same
> responsibilities.
>

Maybe I'm reading the intent of your above statement incorrectly.  But let
me clarify what I mean.

I am saying that if, as part of developing the solutions to the problems
herein outlined, we deliberately deny any notion of namespace hierarchy
(i.e., because "structure" of the DNS is outside the scope of the working
group) then we are limiting our resources to come up with a viable,
effective, solution, all things considered.  I am not saying that we must
*only* use the DNS structure, that we *must* use the DNS structure at all,
or that somehow changing the DNS structure should be within scope.  But
explicitly moving it out of scope makes things unnecessarily complicated,
particularly because despite all the abstract terminology, the identifiers
we are talking about are, in fact, DNS domain names.

Casey

--001a113ecf46a31a810508b4b2f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 1:21 PM, Andrew Sullivan <span dir=
=3D"ltr">&lt;<a href=3D"mailto:ajs@anvilwalrusden.com" target=3D"_blank">aj=
s@anvilwalrusden.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<span>On Tue, Nov 25, 2014 at 01:18:39PM -0500, Casey Deccio wrote:<br>
&gt; &gt; The structure of the DNS and the<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0administrative boundaries in the DNS are entir=
ely out of scope for<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0the working group.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Here I disagree.=C2=A0 What good would it do us to move this out of sc=
ope?<br>
<br>
</span>There already is a WG that has that in scope, and I would expect the=
<br>
IESG to be reluctant to charter two WGs with the same<br>
responsibilities. <br></blockquote><div><br></div><div>Maybe I&#39;m readin=
g the intent of your above statement incorrectly.=C2=A0 But let me clarify =
what I mean.<br><br>I am saying that if, as part of developing the solution=
s to the problems herein outlined, we deliberately deny any notion of names=
pace hierarchy (i.e., because &quot;structure&quot; of the DNS is outside t=
he scope of the working group) then we are limiting our resources to come u=
p with a viable, effective, solution, all things considered.=C2=A0 I am not=
 saying that we must *only* use the DNS structure, that we *must* use the D=
NS structure at all, or that somehow changing the DNS structure should be w=
ithin scope.=C2=A0 But explicitly moving it out of scope makes things unnec=
essarily complicated, particularly because despite all the abstract termino=
logy, the identifiers we are talking about are, in fact, DNS domain names.<=
br></div><div><br></div><div>Casey<br></div></div></div></div>

--001a113ecf46a31a810508b4b2f9--


From nobody Tue Nov 25 12:31:40 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11551A8709 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level: 
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpGNQ3eDHkdl for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:30:14 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D341A7005 for <dbound@ietf.org>; Tue, 25 Nov 2014 12:30:14 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAPKUA03021306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <dbound@ietf.org>; Tue, 25 Nov 2014 12:30:14 -0800
Message-ID: <5474E6C5.8090502@dcrocker.net>
Date: Tue, 25 Nov 2014 12:29:57 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dbound@ietf.org
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <20141125174605.GN5479@mx1.yitter.info>
In-Reply-To: <20141125174605.GN5479@mx1.yitter.info>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Nov 2014 12:30:14 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6sMsjBjRChc6GBiESnQGsVUfm7U
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 20:30:16 -0000

On 11/25/2014 9:46 AM, Andrew Sullivan wrote:
> I think what you need is something like this:
> 
>     For the purposes of this work, domain names are approached as
>     identifiers used in other services, and not as DNS names in
>     themselves.  The working group is not chartered to do any work on
>     management of the DNS itself.  The structure of the DNS and the
>     administrative boundaries in the DNS are entirely out of scope for
>     the working group.


I believe I'm starting to understand what is intended.  I still think
that it's an extremely important point for us to share clarity about,
where 'us' needs to be very broad-based.  So the charter needs to
explain the issue thoroughly enough to make it likely that non-savants
will understand it.

Alas I think that Andrew's text, above, is still far too cryptic, IMO.

(BTW, I take the point about 'domain name' as distinct from "DNS" and
suggest that reference to the DNS be limited to very specific
implementation details.)


With an attempt to avoid rambling and verbosity but the expectation that
neither goal has been achieved, please consider the following discourse
rather than proposed text:


   Domain Names offer a namespace that is hierarchical, but otherwise
unstructured.  Besides the relationships of parent, child and sibling,
the nodes in a domain names do not have structural attributes, such as
indicating that one name is 'related' to another according to some set
of policies or procedures.

   Examples of such relationships include authority boundaries within
the hierarchy and across the hierarchy.  For the former, a 'parent'
domain name is sometimes classed as the organizational domain, to
indicate that the parent domain is at the top of a hiearchy defines a
transition from one "outside" administrative authority to another that
is "inside" the organization. Hence there would need to be a way to
indicate that example.comis the organizational domain for www.example.com.

   Similarly two domain names that might share no part of the domain
name hierarchy other than the domain name root might be subject to the
same administrative authority.  Example.com and example.net could be
controlled by the same organization.

   The requirement to indicate specific relationships between two domain
names depends upon the type of application service using (or asserting)
that relationship.  While the units of concern are still domain names,
they are domain names used within application-specific contexts.

   The working group will define one or more mechanisms to permit
indication and discovery of relationships between domain names,
including indication of the application use(s) of each type of
relationship that is defined.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Tue Nov 25 12:32:46 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627E41A7005 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsnP8EHdaItO for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:30:31 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EC51A884E for <dbound@ietf.org>; Tue, 25 Nov 2014 12:30:31 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2140A8A035 for <dbound@ietf.org>; Tue, 25 Nov 2014 20:30:28 +0000 (UTC)
Date: Tue, 25 Nov 2014 15:30:22 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141125203022.GA6613@mx1.yitter.info>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <20141125174605.GN5479@mx1.yitter.info> <CAEKtLiQiBXaDgT5xZzjaUmMi=R4xjpk0L9RJbGWbD1ySVDgPYA@mail.gmail.com> <20141125182112.GO5479@mx1.yitter.info> <CAEKtLiQG3Shhy0H=MASsvWzYUNvfiiYOvGaP=m07x7HfQobKwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEKtLiQG3Shhy0H=MASsvWzYUNvfiiYOvGaP=m07x7HfQobKwA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ZOgg5RXtkQLTGm2Chv0ny6ob3iw
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 20:30:35 -0000

On Tue, Nov 25, 2014 at 03:24:27PM -0500, Casey Deccio wrote:

> (i.e., because "structure" of the DNS is outside the scope of the working
> group) 

I think you're reading more in what I said than what I intended, so
that suggests the text isn't clear.

My point is that the WG ought to be constrained from developing
anything about DNS operations _themselves_, because we already have a
WG to do that.  We're talking about how applications use identifiers
that come from the DNS, and not how the DNS uses things in the DNS.
Does that make clearer what I'm trying to say?

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Tue Nov 25 12:34:58 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C74E1A886C for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhPXyvmyan4c for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:32:55 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CE51A885C for <dbound@ietf.org>; Tue, 25 Nov 2014 12:32:55 -0800 (PST)
Received: (qmail 11808 invoked from network); 25 Nov 2014 20:32:53 -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=2e1f.5474e775.k1411; bh=aYDUqXu6owj0WNI8o2+Z+DpZJEmTOI3wRD539SRqyCw=; b=PCK6fUImAh2+ANrAvI53ZM9LMZonFydU8sPCt6i2izwme0TeRfidumOWHwLMA+xHRSd6HoGWcsKJHfCDnDDpK6IWpHo9iXMZKuSdAu1u28puHr7Hpe0dNVo29Egj6Cr7s/+PlhYcdxG3rD/iy1j5RzaUJdZGN8lD8cQs+daiCYekeRZkdRD87H9IGvLdVyiQ11hdVyHJhk2a+8LRyhWbxe2DGeMPq5DdoMKZ0tybFoZKYtQHydLBiy5+cprSOg6N
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=2e1f.5474e775.k1411; bh=aYDUqXu6owj0WNI8o2+Z+DpZJEmTOI3wRD539SRqyCw=; b=LV6L4+jnb/QF5u50U4K1X3+mYKMZRxmsa07THzODClrPDO9jXlbWZRAxa59iYGpWV9J728drWHunCDC4URfRlfNUcvES35Vk7L7gHZ/xE+EOz3RsToKXV2YQXbdJaIXP7FqojwsiSsYvY/SEJoKGlZtCuVI06ICwlhgLuPS4uSwLCefY8DWyHbiBxF3kOzAvjGV7mQpslq321PpnRj2uHIb93vMpPkJl+sO20cQtlKC+TpLjtNfn4leVAoEOKPdi
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; 25 Nov 2014 20:32:53 -0000
Date: 25 Nov 2014 15:32:53 -0500
Message-ID: <alpine.OSX.2.11.1411251531030.61207@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Edward Lewis" <edward.lewis@icann.org>
In-Reply-To: <D09A1C9B.738A%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/CUXJOmuMTgOXjK2_pgdO3TyOFu8
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 20:32:56 -0000

> sending agent of a mail message, make it clear that it is not about the
> domain name system.

Unless you're proposing to describe relations among arbitrary strings that 
can't be looked up in the DNS, it's most definitely about domain names.

I sympathize with your concern that some people are unable to see the DNS 
other than as zone cuts and RRs, but unless I totally misunderstand what 
we're doing, the identifiers we're talking about are in fact names in the 
DNS.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Tue Nov 25 12:56:29 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C665C1A7D81 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sbgS-cCxyAT for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 12:55:14 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36C21A6F59 for <dbound@ietf.org>; Tue, 25 Nov 2014 12:55:13 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id r20so2829232wiv.14 for <dbound@ietf.org>; Tue, 25 Nov 2014 12:55:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=N/V+/NH8zYT/qmVv0Ta3pa7hxwj9NufZSd9eOY8U/JY=; b=Roo8t1WPGb0z41E/NYabsou81g9Ob/NogrlXl2Y27EQ/KF2uvPf7vRzMJDY5Cdkb+5 V9Voh8qfs8KQ1LoGvNU88ePMESikYq+cDFueOJmhg6rUw0rFm8CvlUBxkzMfa2Gv6+ng Mcy5jDzEJdFZqYnVjgwFFuSQGolmIe7zNFL2U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N/V+/NH8zYT/qmVv0Ta3pa7hxwj9NufZSd9eOY8U/JY=; b=C48+bBhEEeHN2V12oTDThnO7T1g/yKRR6GAiZfXXBtBJH8iSc0t/hEIkhqu7QvUJWt D6rjYDejPB0Zjs7DQzakndIN4oy8MRqQtSIl5aJU+S97LUUL1LIt1wkKP9cyvat2Q29N JcjONdOMZYN3rVlSUBVytNcd87ure2uEzjvZQMIbkKkEMDSE086z2vx2rusaHA+OOmNu dfI7O83iE08hV36D0vl43VKxXunRSiRVUGITiSBE1GKqUPFqMREE1w0iPshOGOOf525N yUzv7HIIAiFMFarvvn8AMJkPsSCRxsNQmV9LPETKcICmEfdXYHtfzj3mOCC/JCePqmm1 EIMg==
X-Gm-Message-State: ALoCoQkGnA+VC8aF0ZnMiCvZ5O0M9FvCQYo4ds4aZ7GS/UP2xnyk5PNGFU8IdmNrm6ZaHFjIIBko
MIME-Version: 1.0
X-Received: by 10.180.211.79 with SMTP id na15mr29034790wic.36.1416948912652;  Tue, 25 Nov 2014 12:55:12 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Tue, 25 Nov 2014 12:55:12 -0800 (PST)
In-Reply-To: <D09A3B3B.73B8%edward.lewis@icann.org>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org> <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com> <D09A3B3B.73B8%edward.lewis@icann.org>
Date: Tue, 25 Nov 2014 12:55:12 -0800
X-Google-Sender-Auth: 0unPIuywphkmYMmNWhbOcJhG3zU
Message-ID: <CABuGu1qtW-MYUhnSQQuiyEtd9J5BGypdgss-xp0vbzHPe7TWMw@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c388209ab2890508b520f6
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/DWufVkqRefI7LVwxRL-Sz3w5EAA
Cc: "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 20:55:17 -0000

--001a11c388209ab2890508b520f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 25, 2014 at 11:02 AM, Edward Lewis <edward.lewis@icann.org>
wrote:

> the problem [is] entirely external to the DNS as a system.
>
It=E2=80=99s about how domain names are manipulated by
> applications.  Particularly manipulation of domain names - not general
> identifiers
>

Bingo! "Manipulated" and "considered associated with one another" - now if
we could come up with appropriate language to specify this in the charter.

--Kurt

--001a11c388209ab2890508b520f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On Tue, Nov 25, 2014 at 11:02 A=
M, Edward Lewis <span dir=3D"ltr">&lt;<a href=3D"mailto:edward.lewis@icann.=
org" target=3D"_blank">edward.lewis@icann.org</a>&gt;</span> wrote:<br><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>the problem [is]=
 entirely external to the DNS as a system.=C2=A0 <br></div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div id=3D":1dg" class=3D"a3s" style=3D"overflo=
w:hidden">It=E2=80=99s about how domain names are manipulated by<br>
applications.=C2=A0 Particularly manipulation of domain names - not general=
<br>
identifiers</div></blockquote></div><br></div><div class=3D"gmail_extra">Bi=
ngo! &quot;Manipulated&quot; and &quot;considered associated with one anoth=
er&quot; - now if we could come up with appropriate language to specify thi=
s in the charter.<br><br></div><div class=3D"gmail_extra">--Kurt<br></div><=
div class=3D"gmail_extra"><br></div></div>

--001a11c388209ab2890508b520f6--


From nobody Tue Nov 25 13:39:04 2014
Return-Path: <suzworldwide@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7D41A890E for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 13:37:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFLyEx7-oMbv for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 13:37:02 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5FC1A8906 for <dbound@ietf.org>; Tue, 25 Nov 2014 13:36:58 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id l89so1110306qgf.38 for <dbound@ietf.org>; Tue, 25 Nov 2014 13:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2JdpH8yjcvAyEtyYKhYRG67QLNfG+GTXjod+21xoOVs=; b=c30Npy5XghUC+6J5lnujgbQN7SmRGi+jF7yiApw6rYPW2xGO78CUkbkqPukqRMdIAd lJo6HyVW3cXMdK/uPfwm3ZyYziTxWhq8mosZA5oVgZWmTmquO5QXCp9urOj52x0Ds3rV +W5aFWLlXtUoeMk4xSBT0EEGM7OjdCg1B57oqqG8Zqheam7ZTa7QIRRhFMwoJUt05nEs k6muxwPkDZJuBAe32wdeaVUurq/M9gVF2yxhmHDYM3ESJkSL4UXBQFA+i7kd+RIXkc2t yQ32Ew3LPw79qpLESytL951ltjQgTHODcfVVcYYHpBASnN/IHXAXgXt3L0hDdxHfn4kA 5lcA==
X-Received: by 10.224.94.9 with SMTP id x9mr25203507qam.45.1416951417712; Tue, 25 Nov 2014 13:36:57 -0800 (PST)
Received: from [10.0.0.15] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by mx.google.com with ESMTPSA id q4sm2209562qam.7.2014.11.25.13.36.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 13:36:56 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_920F629B-1594-475A-9369-0CB2D7C19EDB"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <CABuGu1qtW-MYUhnSQQuiyEtd9J5BGypdgss-xp0vbzHPe7TWMw@mail.gmail.com>
Date: Tue, 25 Nov 2014 16:36:55 -0500
Message-Id: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org> <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com> <D09A3B3B.73B8%edward.lewis@icann.org> <CABuGu1qtW-MYUhnSQQuiyEtd9J5BGypdgss-xp0vbzHPe7TWMw@mail.gmail.com>
To: Kurt Andersen <kboth@drkurt.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/R445BWzV0OLTJ1XmvxaQ5OXgp9E
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 21:37:04 -0000

--Apple-Mail=_920F629B-1594-475A-9369-0CB2D7C19EDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Maybe another way to make the distinction we're talking about: DNS =
*namespace* but not DNS *protocol*?

The association between names in DNS protocol is limited to namespace =
hierarchy (with and without zone cuts, which also have protocol =
significance) and the semantics of specific RRtypes. We may be looking =
to express and manipulate other kinds of association among names in the =
DNS namespace for manipulation by, and to the benefit of, applications.

Does this help?

On Nov 25, 2014, at 3:55 PM, Kurt Andersen <kboth@drkurt.com> wrote:

> On Tue, Nov 25, 2014 at 11:02 AM, Edward Lewis =
<edward.lewis@icann.org> wrote:
> the problem [is] entirely external to the DNS as a system. =20
> It=92s about how domain names are manipulated by
> applications.  Particularly manipulation of domain names - not general
> identifiers
>=20
> Bingo! "Manipulated" and "considered associated with one another" - =
now if we could come up with appropriate language to specify this in the =
charter.
>=20
> --Kurt
>=20
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound


--Apple-Mail=_920F629B-1594-475A-9369-0CB2D7C19EDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Maybe =
another way to make the distinction we're talking about: DNS *namespace* =
but not DNS *protocol*?<div><br></div><div>The association between names =
in DNS protocol is limited to namespace hierarchy (with and without zone =
cuts, which also have protocol significance) and the semantics of =
specific RRtypes. We may be looking to express and manipulate other =
kinds of association among names in the DNS namespace for manipulation =
by, and to the benefit of, applications.</div><div><br></div><div>Does =
this help?</div><div><br><div><div>On Nov 25, 2014, at 3:55 PM, Kurt =
Andersen &lt;<a href=3D"mailto:kboth@drkurt.com">kboth@drkurt.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">On Tue, Nov =
25, 2014 at 11:02 AM, Edward Lewis <span dir=3D"ltr">&lt;<a =
href=3D"mailto:edward.lewis@icann.org" =
target=3D"_blank">edward.lewis@icann.org</a>&gt;</span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the problem [is] =
entirely external to the DNS as a system.&nbsp; =
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":1dg" =
class=3D"a3s" style=3D"overflow:hidden">It=92s about how domain names =
are manipulated by<br>
applications.&nbsp; Particularly manipulation of domain names - not =
general<br>
identifiers</div></blockquote></div><br></div><div =
class=3D"gmail_extra">Bingo! "Manipulated" and "considered associated =
with one another" - now if we could come up with appropriate language to =
specify this in the charter.<br><br></div><div =
class=3D"gmail_extra">--Kurt<br></div><div =
class=3D"gmail_extra"><br></div></div>
_______________________________________________<br>Dbound mailing =
list<br><a =
href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>https://www.ietf.or=
g/mailman/listinfo/dbound<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_920F629B-1594-475A-9369-0CB2D7C19EDB--


From nobody Tue Nov 25 13:52:40 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23BE1A1AC6 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 13:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv-rkUtWIzbc for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 13:50:15 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C111A1A5F for <dbound@ietf.org>; Tue, 25 Nov 2014 13:50:15 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id rl12so1470897iec.2 for <dbound@ietf.org>; Tue, 25 Nov 2014 13:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eyXcHID664PzW739g/3Nd412T1IyZftdGFLEdVJjhXQ=; b=EUEY5dtUWtZ3B7kPb8FHInW51NgAbR4UIgWEHrI1j5uNN7dRKdZ/TO0q50o6CupBrW cDlvheLG5Wi99hsmBgVY1Ts3rO7mvWDJDxo5hdH1F/gEVCBGDQGpS1TlDOdb9/nLKDaf BSjIHFgrtjCpBI5VeF9e1IGIrCdtpFSLWItmg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eyXcHID664PzW739g/3Nd412T1IyZftdGFLEdVJjhXQ=; b=kargNVePrCVAK8YQ9yxzNn1KdCdohPeaHxbxcMtrb/k2GxgVc/Wu1RTcLu2k0UyVq9 UaDMkjTo1wRq9kjgp0wu/F0fVFIw8GDv6zvaWhd3GGSJo2+oEkndukfzsYoIooVwSTYK /ht0KUh7RXz4ufFLtkL1l4WLjTkr9yULo9dQ5JvZ7Ea1XNhM7CtjaAPMYlYlwDAiZnrB 5wlENlBRWf8yHsvIAQtmZbb8NikcUuHC9uT2YB9XxnIygAivkl9VCl2pL3znQ05NV7dn o7VSRXOhTFrrksH3Jrxwvb4AQASgzWzEU1ZjFz2XTK2DoQnB283ZIfqx6RhFq3WzHN5g pkAA==
X-Gm-Message-State: ALoCoQnJEJiBG/7IKSet8s6N24+RIyobpw8AtA2dQo3MwrOSastRE2UQubMcNyu/J175/JfiDgPm
MIME-Version: 1.0
X-Received: by 10.43.78.196 with SMTP id zn4mr32087286icb.10.1416952214563; Tue, 25 Nov 2014 13:50:14 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 25 Nov 2014 13:50:14 -0800 (PST)
In-Reply-To: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org> <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com> <D09A3B3B.73B8%edward.lewis@icann.org> <CABuGu1qtW-MYUhnSQQuiyEtd9J5BGypdgss-xp0vbzHPe7TWMw@mail.gmail.com> <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
Date: Tue, 25 Nov 2014 16:50:14 -0500
Message-ID: <CAEKtLiTS=6d=_-1rhOu5jSKCeKrJ2xBgpbsyNvsuA-=z3L21WQ@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3b83469c5b30508b5e5b6
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/PkJjTQSLS8X4WNkzMhOj50jgFu0
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 21:50:16 -0000

--001a11c3b83469c5b30508b5e5b6
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 25, 2014 at 4:36 PM, Suzanne Woolf <suzworldwide@gmail.com>
wrote:

> Maybe another way to make the distinction we're talking about: DNS
> *namespace* but not DNS *protocol*?
>
>
Yes!


> The association between names in DNS protocol is limited to namespace
> hierarchy (with and without zone cuts, which also have protocol
> significance) and the semantics of specific RRtypes. We may be looking to
> express and manipulate other kinds of association among names in the DNS
> namespace for manipulation by, and to the benefit of, applications.
>
>
Sounds about right to me.

Casey

--001a11c3b83469c5b30508b5e5b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 4:36 PM, Suzanne Woolf <span dir=
=3D"ltr">&lt;<a href=3D"mailto:suzworldwide@gmail.com" target=3D"_blank">su=
zworldwide@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-=
wrap:break-word">Maybe another way to make the distinction we&#39;re talkin=
g about: DNS *namespace* but not DNS *protocol*?<div><br></div></div></bloc=
kquote><div><br></div><div>Yes!<br>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div style=3D"word-wrap:break-word"><div></div><div>The association =
between names in DNS protocol is limited to namespace hierarchy (with and w=
ithout zone cuts, which also have protocol significance) and the semantics =
of specific RRtypes. We may be looking to express and manipulate other kind=
s of association among names in the DNS namespace for manipulation by, and =
to the benefit of, applications.</div><div><br></div></div></blockquote><di=
v><br></div>Sounds about right to me.<br><br></div><div class=3D"gmail_quot=
e">Casey<br></div></div></div>

--001a11c3b83469c5b30508b5e5b6--


From nobody Tue Nov 25 15:40:35 2014
Return-Path: <jothan@jothan.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D11A6FC5 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 15:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDS0gFMeZvA5 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 15:40:29 -0800 (PST)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7181A1EF7 for <dbound@ietf.org>; Tue, 25 Nov 2014 15:40:28 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id f15so1597423lbj.41 for <dbound@ietf.org>; Tue, 25 Nov 2014 15:40:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Z9d0uMr/yf15T1O+DQFLoZkeqXai2qqdkg6XmOMs7f4=; b=BwSx2JjrHdU55lDgnA0acNYUMIVwirJ9WrqaGlAyKV9308CsIhDifozmrJOX5T24w1 jx70HLG6Kt6PbODz5iUWXQdwXCL8N4aajYS9f6AV/qBRBhL0dbUL9yQCfIWCqz0MWtma cC0VPFW/hzJZVV+0B5i8GehGP1t3/HkIxRlTFY4A4250DCMZleAqw8m2i/qbgWqfn2Bh 5WXcbXWoqzBogrBRfb8sJvU1r4FpXXS4Z1Ub3NezTA7cio05JQeBnftj/3EKl+uc22J7 wjXC/XUoeumlcNYKBxVhTysVvaD7c39KwYn4x08DEu3u8ddLid1G8CIPewHyNz9aGbHJ f6xQ==
X-Gm-Message-State: ALoCoQmDuhr/DqdHTiKuw+7lj6Pa5G3X27ljE2bJFEwXD0luHQZ8hAV/5noHovLGdHpqaTVhxRA0
X-Received: by 10.153.5.33 with SMTP id cj1mr11275641lad.65.1416958827141; Tue, 25 Nov 2014 15:40:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.89.79 with HTTP; Tue, 25 Nov 2014 15:39:56 -0800 (PST)
In-Reply-To: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
References: <CAL0qLwZpcDLKsEZpNWt_u2X23w-uL3TCy7KRwaYtHSjm6UHC_g@mail.gmail.com> <D099140A.7283%edward.lewis@icann.org> <CAL0qLwbzx7w88C1LHQ0VL3XgZd4f6f8LNiTX7=ZuTuNM+n9d6A@mail.gmail.com> <CAL0qLwabcbW4mEmjV94m4nKmKvcCLBP3CmrhePefpqfL=rGF6A@mail.gmail.com> <D09A1C9B.738A%edward.lewis@icann.org> <5474BC68.6010005@dcrocker.net> <D09A3686.73B0%edward.lewis@icann.org> <CAL0qLwYDznivJJ4SphMVhOPmhYVwrYVFm+rRMbfWp0yTRvG3OA@mail.gmail.com> <D09A3B3B.73B8%edward.lewis@icann.org> <CABuGu1qtW-MYUhnSQQuiyEtd9J5BGypdgss-xp0vbzHPe7TWMw@mail.gmail.com> <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
From: Jothan Frakes <jothan@jothan.com>
Date: Tue, 25 Nov 2014 15:39:56 -0800
Message-ID: <CAGrS0F+8e856MAnsOeRMy4jM5Pa__wLQuDqH=BQ5xgsK_yu_+w@mail.gmail.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary=001a113496288da88c0508b76f48
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/CLIaJNwAPszL7nCpAYAN9RQQufY
Cc: Kurt Andersen <kboth@drkurt.com>, "Murray S. Kucherawy" <superuser@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 23:40:31 -0000

--001a113496288da88c0508b76f48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Brilliant suggestion Suzanne.


Jothan Frakes
Tel: +1.206-355-0230


On Tue, Nov 25, 2014 at 1:36 PM, Suzanne Woolf <suzworldwide@gmail.com>
wrote:

> Maybe another way to make the distinction we're talking about: DNS
> *namespace* but not DNS *protocol*?
>
> The association between names in DNS protocol is limited to namespace
> hierarchy (with and without zone cuts, which also have protocol
> significance) and the semantics of specific RRtypes. We may be looking to
> express and manipulate other kinds of association among names in the DNS
> namespace for manipulation by, and to the benefit of, applications.
>
> Does this help?
>
> On Nov 25, 2014, at 3:55 PM, Kurt Andersen <kboth@drkurt.com> wrote:
>
> On Tue, Nov 25, 2014 at 11:02 AM, Edward Lewis <edward.lewis@icann.org>
> wrote:
>
>> the problem [is] entirely external to the DNS as a system.
>>
> It=E2=80=99s about how domain names are manipulated by
>> applications.  Particularly manipulation of domain names - not general
>> identifiers
>>
>
> Bingo! "Manipulated" and "considered associated with one another" - now i=
f
> we could come up with appropriate language to specify this in the charter=
.
>
> --Kurt
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>
>
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>
>

--001a113496288da88c0508b76f48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Brilliant suggestion Suzanne.</div><div class=3D"gmail_ext=
ra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr">=
<br>Jothan Frakes<br>Tel: +1.206-355-0230<br><br></div></div></div>
<br><div class=3D"gmail_quote">On Tue, Nov 25, 2014 at 1:36 PM, Suzanne Woo=
lf <span dir=3D"ltr">&lt;<a href=3D"mailto:suzworldwide@gmail.com" target=
=3D"_blank">suzworldwide@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word">Maybe another way to ma=
ke the distinction we&#39;re talking about: DNS *namespace* but not DNS *pr=
otocol*?<div><br></div><div>The association between names in DNS protocol i=
s limited to namespace hierarchy (with and without zone cuts, which also ha=
ve protocol significance) and the semantics of specific RRtypes. We may be =
looking to express and manipulate other kinds of association among names in=
 the DNS namespace for manipulation by, and to the benefit of, applications=
.</div><div><br></div><div>Does this help?</div><div><br><div><div><div cla=
ss=3D"h5"><div>On Nov 25, 2014, at 3:55 PM, Kurt Andersen &lt;<a href=3D"ma=
ilto:kboth@drkurt.com" target=3D"_blank">kboth@drkurt.com</a>&gt; wrote:</d=
iv><br></div></div><blockquote type=3D"cite"><div><div class=3D"h5"><div di=
r=3D"ltr"><div class=3D"gmail_extra">On Tue, Nov 25, 2014 at 11:02 AM, Edwa=
rd Lewis <span dir=3D"ltr">&lt;<a href=3D"mailto:edward.lewis@icann.org" ta=
rget=3D"_blank">edward.lewis@icann.org</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">the problem [is] entirely e=
xternal to the DNS as a system.=C2=A0 <br></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div style=3D"overflow:hidden">It=E2=80=99s about how domain nam=
es are manipulated by<br>
applications.=C2=A0 Particularly manipulation of domain names - not general=
<br>
identifiers</div></blockquote></div><br></div><div class=3D"gmail_extra">Bi=
ngo! &quot;Manipulated&quot; and &quot;considered associated with one anoth=
er&quot; - now if we could come up with appropriate language to specify thi=
s in the charter.<br><br></div><div class=3D"gmail_extra">--Kurt<br></div><=
div class=3D"gmail_extra"><br></div></div></div></div><span class=3D"">
_______________________________________________<br>Dbound mailing list<br><=
a href=3D"mailto:Dbound@ietf.org" target=3D"_blank">Dbound@ietf.org</a><br>=
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br></span></blockquote></d=
iv><br></div></div><br>_______________________________________________<br>
Dbound mailing list<br>
<a href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br>
<br></blockquote></div><br></div>

--001a113496288da88c0508b76f48--


From nobody Tue Nov 25 16:47:34 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6E1A7113 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 16:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbnNx3VaMfmv for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 16:47:32 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772571A6FFD for <dbound@ietf.org>; Tue, 25 Nov 2014 16:47:32 -0800 (PST)
Received: (qmail 45671 invoked from network); 26 Nov 2014 00:47:30 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 26 Nov 2014 00:47:30 -0000
Date: 26 Nov 2014 00:47:09 -0000
Message-ID: <20141126004709.26151.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/C9J9FVEo1_k11jqmNje4rx_6syE
Cc: suzworldwide@gmail.com
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 00:47:33 -0000

In article <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> you write:
>Maybe another way to make the distinction we're talking about: DNS *namespace* but not DNS *protocol*?

Sounds reasonable to me.

R's,
John


From nobody Tue Nov 25 17:01:49 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041CD1A86E1 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 17:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxaoNr_PAPZD for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 17:01:44 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75191A6F92 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:01:44 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id hq11so831510vcb.31 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oxMukSOSVn1uXEk9Mfh9u9XTGKBaPMDWsQR6mtcnw9k=; b=H0rY8Mumrw/Y0kx9VdsapxftF7Z7b2FJAHlrJqvGNHciTdO/lShkc4IjwlfLW+xVRF HgpZQ3pbhYLEfk0a7FwuWuzlzpM/G025mYTodLspHY9QKNC2qV3+H/7LEtf7rX0DNuNA m8TPUf4Mm8klqvkfs/ipUmhM0CLmdHtsp9AwcGE9AMget0BvAo3ZB1cfQ+2p1vBedpA+ KTM6p9x04Zu6BCrkvUhdYnflair2yXH60woJgjG9FGwzbQZYyPIucbQ7JZQb0Q7SHnwZ yL3JrBvP81HV5adJGXgkIRK4LzNJQZYUOLPLGcha51KWxOUVT2JUarVXBNyG2SW0Ip0/ HSEw==
MIME-Version: 1.0
X-Received: by 10.52.18.98 with SMTP id v2mr13768708vdd.86.1416963703851; Tue, 25 Nov 2014 17:01:43 -0800 (PST)
Received: by 10.52.79.66 with HTTP; Tue, 25 Nov 2014 17:01:43 -0800 (PST)
In-Reply-To: <20141126004709.26151.qmail@ary.lan>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan>
Date: Tue, 25 Nov 2014 17:01:43 -0800
Message-ID: <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a1136977a3a52ac0508b892cd
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/t9QbG5cTnaQghFOq6lziLhMhG_0
Cc: Suzanne Woolf <suzworldwide@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 01:01:47 -0000

--001a1136977a3a52ac0508b892cd
Content-Type: text/plain; charset=UTF-8

Rather than repeatedly posting the whole thing here, I'm just going to keep
updating this as people make suggestions until you all tell me to stop and
circulate it for approval.  The first place it will go once it's stable
here is apps-discuss, and then to the IESG.

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

You can see individual edits and all that through the github UI.

So how's it look now?

-MSK


On Tue, Nov 25, 2014 at 4:47 PM, John Levine <johnl@taugh.com> wrote:

> In article <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> you write:
> >Maybe another way to make the distinction we're talking about: DNS
> *namespace* but not DNS *protocol*?
>
> Sounds reasonable to me.
>
> R's,
> John
>
> _______________________________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>

--001a1136977a3a52ac0508b892cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Rather than repeatedly posting the whole thing here, =
I&#39;m just going to keep updating this as people make suggestions until y=
ou all tell me to stop and circulate it for approval.=C2=A0 The first place=
 it will go once it&#39;s stable here is apps-discuss, and then to the IESG=
.<br><br><a href=3D"https://github.com/mskucherawy/docs/blob/master/charter=
-dbound">https://github.com/mskucherawy/docs/blob/master/charter-dbound</a>=
<br><br></div><div>You can see individual edits and all that through the gi=
thub UI.<br><br></div><div>So how&#39;s it look now?<br></div><div><br></di=
v>-MSK<br><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Tue, Nov 25, 2014 at 4:47 PM, John Levine <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">In article &l=
t;<a href=3D"mailto:F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com">F70D6D8=
2-662B-40A0-917A-45E2C60B1D72@gmail.com</a>&gt; you write:<br>
&gt;Maybe another way to make the distinction we&#39;re talking about: DNS =
*namespace* but not DNS *protocol*?<br>
<br>
</span>Sounds reasonable to me.<br>
<br>
R&#39;s,<br>
John<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Dbound mailing list<br>
<a href=3D"mailto:Dbound@ietf.org">Dbound@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dbound" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/dbound</a><br>
</div></div></blockquote></div><br></div>

--001a1136977a3a52ac0508b892cd--


From nobody Tue Nov 25 17:26:55 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D11A86E1 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 17:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUa05QUsN5nz for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 17:26:52 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271601A6F92 for <dbound@ietf.org>; Tue, 25 Nov 2014 17:26:52 -0800 (PST)
Received: (qmail 50151 invoked from network); 26 Nov 2014 01:26:49 -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=c3e6.54752c59.k1411; bh=0r3EIKQKvZWg630Kvs/7CsIwPdP096rCXDHL/iNnLRo=; b=sF8oI9dX+LBTUEcPt0y1fq/Wf8Yv6DewJFkEEgkSCagNvymh0ktwCYVEetVlMcIgUC/BN8XIJDUZtKikjnicuT1G/8hUDL/xOU9BjnwKeJCX80lk7FZW5yqKWI8Kar102aA6e5iYlmrlUSXhPpqEz3DPsMm904IW3Rcc5MO/++NLMSYr/q5w+9woZPYrWE/PhjVabcV3AgwimrG85SSQwubLvWNKmcW8xrTMVDoY/A76zljPjMh8JIcp1nd4PIiu
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=c3e6.54752c59.k1411; bh=0r3EIKQKvZWg630Kvs/7CsIwPdP096rCXDHL/iNnLRo=; b=NUtjSKHITThiMcBfe76ebSrR2X2SdXWFR4SykAgZRs6VXch1vSqkbWmniK8JfIaVYUHr9LcUu9G2WFi7d0qB4WoPUVK7dqb/5SF9bzxW/9LaPnfnt2dwlUL1FBJfxpBJrXpdxWN0ZEhqeWFCEk8IMQRvK5cyfewpIREDFNZXwpQFU/sM5x38vyIiY2WCEM+KeE3eAxF35L33ki241xwOZ3+fjUBFlU5WmGSxpKiEvKCbsmjY4F2/KPKx3dDIFm+I
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 Nov 2014 01:26:49 -0000
Date: 25 Nov 2014 20:26:49 -0500
Message-ID: <alpine.OSX.2.11.1411252026330.62369@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
In-Reply-To: <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
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: http://mailarchive.ietf.org/arch/msg/dbound/-DsuyOdmpFpsPy0zjXvH_K3-1Zc
Cc: Suzanne Woolf <suzworldwide@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 01:26:53 -0000

> So how's it look now?

I'm OK with this version.  Tnx.

>
> -MSK
>
>
> On Tue, Nov 25, 2014 at 4:47 PM, John Levine <johnl@taugh.com> wrote:
>
>> In article <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> you write:
>>> Maybe another way to make the distinction we're talking about: DNS
>> *namespace* but not DNS *protocol*?
>>
>> Sounds reasonable to me.
>>
>> R's,
>> John
>>
>> _______________________________________________
>> Dbound mailing list
>> Dbound@ietf.org
>> https://www.ietf.org/mailman/listinfo/dbound
>>
>

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Tue Nov 25 19:30:33 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6C61A871E for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 19:30:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHsAPPcpsmTL for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 19:30:30 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB801A8034 for <dbound@ietf.org>; Tue, 25 Nov 2014 19:30:30 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id b13so2565676wgh.18 for <dbound@ietf.org>; Tue, 25 Nov 2014 19:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=KOYzgdoHIsnJzf7Xoh82UzOXxB8/Qhj9fYtsjWLmcnQ=; b=PpBYcWYofzztJ1GFN50SPz8SfQ9fUtbE36yNHGP8ET4eknoXj0UE16dgT0G6Q7Okp/ GaXHyxyRIBQyQd1vzDYgSgSbfqAK0i9vShyCbF2b7Ald9pZFwPI7R8Mm7HDRBq+7i73u D8uwUTPm55S4Lfv4zAFNhmXFUmZWfLULo8T1E=
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:cc:content-type; bh=KOYzgdoHIsnJzf7Xoh82UzOXxB8/Qhj9fYtsjWLmcnQ=; b=lbD+rlMBfXaved09lpSMfaPZzKPiWJLjrcpRjE4MA5N5LT0uc1tkHpwIVPoFVx54cj vtLgs1JE+hNdTMcRpxbfz2m/3EtnNZU7s5Xc/xhQjGVx80w2HXdl2+6bfBj+Nl/ocB67 BA3lHU1ls+pSji1a/y9ds8cPe1uxjIb+L636YJGLoyfZoWMoLiWjaLarx5Vb4YzoaYjn A6g0rEKDi3EpV+kUpX17lrZgdxdWbRDCzGmGNoqBFrGP7K4KZb1cqEu+fib/JwgT6pb2 JJXhy6wpveEiPIEAP8BIGBRzHxIOGYcjIpEPPY7gvqESpaEtGNJFXxq+UZinioXny0TN i7yg==
X-Gm-Message-State: ALoCoQn2/APj48rQ+seayJ3Y08CaXV/uzc42HgC9Pnhvzrl/AjPd94iDCEQ6f67vmVYwo2lQeLEk
MIME-Version: 1.0
X-Received: by 10.194.122.66 with SMTP id lq2mr43797250wjb.54.1416972629070; Tue, 25 Nov 2014 19:30:29 -0800 (PST)
Received: by 10.194.151.165 with HTTP; Tue, 25 Nov 2014 19:30:28 -0800 (PST)
In-Reply-To: <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
Date: Tue, 25 Nov 2014 22:30:28 -0500
Message-ID: <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
Cc: "dbound@ietf.org" <dbound@ietf.org>
Content-Type: multipart/alternative; boundary=089e01177a413671c30508baa651
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/sQ6gaVnqW-Vq2wtGW6t7YrLJPkM
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 03:30:32 -0000

--089e01177a413671c30508baa651
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 25, 2014 at 8:01 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Rather than repeatedly posting the whole thing here, I'm just going to
> keep updating this as people make suggestions until you all tell me to stop
> and circulate it for approval.  The first place it will go once it's stable
> here is apps-discuss, and then to the IESG.
>
> https://github.com/mskucherawy/docs/blob/master/charter-dbound
>
> You can see individual edits and all that through the github UI.
>
> So how's it look now?
>
>
Looks good!

I recommended in my earlier comments (and still recommend) that the
following sentence be removed, on the basis that it can be said about any
solution--even those produced by the proposed working group:

"When this list is inaccurate, it exposes a deviation from reality that
degrades service to some and can be exploited by others."

(The recommendation was probably lost in the noise; I didn't see any
comments opposing it.)

Other than that proposed edit, I think it is in good shape.

Cheers,
Casey

--089e01177a413671c30508baa651
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 8:01 PM, Murray S. Kucherawy <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">s=
uperuser@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>Rather than repeatedly posting the whole thing here, I&=
#39;m just going to keep updating this as people make suggestions until you=
 all tell me to stop and circulate it for approval.=C2=A0 The first place i=
t will go once it&#39;s stable here is apps-discuss, and then to the IESG.<=
br><br><a href=3D"https://github.com/mskucherawy/docs/blob/master/charter-d=
bound" target=3D"_blank">https://github.com/mskucherawy/docs/blob/master/ch=
arter-dbound</a><br><br></div><div>You can see individual edits and all tha=
t through the github UI.<br><br></div><div>So how&#39;s it look now?<span><=
font color=3D"#888888"><br></font></span></div><span><font color=3D"#888888=
"><div><br></div></font></span></div></blockquote><div><br></div><div>Looks=
 good!<br><br></div><div>I recommended in my earlier comments (and still re=
commend) that the following sentence be removed, on the basis that it can b=
e said about any solution--even those produced by the proposed working grou=
p:<br></div><div><br>&quot;When this list is inaccurate, it exposes a devia=
tion from reality that
     =20
     =20
       =20
        degrades service to some and can be exploited by others.&quot;<br><=
br>(The recommendation was probably lost in the noise; I didn&#39;t see any=
 comments opposing it.)<br><br></div><div>Other than that proposed edit, I =
think it is in good shape.<br></div><div><br></div><div>Cheers,<br></div><d=
iv>Casey<br></div></div></div></div>

--089e01177a413671c30508baa651--


From nobody Tue Nov 25 21:37:33 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50A1A871D for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 21:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez0Z_14iBa76 for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 21:37:28 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31B31A6FFD for <dbound@ietf.org>; Tue, 25 Nov 2014 21:37:27 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex7so11277465wid.15 for <dbound@ietf.org>; Tue, 25 Nov 2014 21:37:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rZ9EZWjK7MubH53Q+wH0a77KPLSbJf+MdGxmatxi764=; b=gZLPfJLSzwmpnKlK80wEooV68VBixV82Hh1tvvzuxpSFPVOh1zl+NdOEolymKa7MtP dYOnGxiYJGfQDjLyCy+NJB6UUzC8DieXKZ4iH//52XE0Hp5cKk0kgNo0+F+2WtStzpBC Nq59ELYp8eGUIWWrtiiceKlxj93lTqztJGRHaaPX2VKVSGvmvO3/gS/gUSy5vbblBAGL 5uHrtzlHYPGmap1qEiI903yiHDxXTQMhjqOwbi8YAxj1us6PT2VaeOmbnzY5eup+8Jgx FlVgECMEWqJYA0PyzNMD6rVVef0VWgGGNodFGrmJo33m2aozB/VigYUpz7qnRmTopNdX AOVA==
MIME-Version: 1.0
X-Received: by 10.180.14.226 with SMTP id s2mr37768893wic.61.1416980246506; Tue, 25 Nov 2014 21:37:26 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Tue, 25 Nov 2014 21:37:26 -0800 (PST)
In-Reply-To: <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com>
Date: Tue, 25 Nov 2014 21:37:26 -0800
Message-ID: <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Casey Deccio <casey@deccio.net>
Content-Type: multipart/alternative; boundary=f46d04138c9f3f32e60508bc6c07
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/JUIzjjr04ZMd1Vb5CtLoR8I7alo
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 05:37:29 -0000

--f46d04138c9f3f32e60508bc6c07
Content-Type: text/plain; charset=UTF-8

Hi Casey,

On Tue, Nov 25, 2014 at 7:30 PM, Casey Deccio <casey@deccio.net> wrote:

> I recommended in my earlier comments (and still recommend) that the
> following sentence be removed, on the basis that it can be said about any
> solution--even those produced by the proposed working group:
>

> "When this list is inaccurate, it exposes a deviation from reality that
> degrades service to some and can be exploited by others."
>

I did see that comment but I left the sentence in.  In the context in which
it appears, I thought it added useful emphasis to the concern and impetus
for coming up with something better than a table maintained on a
best-effort basis.


> (The recommendation was probably lost in the noise; I didn't see any
> comments opposing it.)
>

I didn't see anyone supporting it either... ;-)

I'm happy to go with consensus in the end, but I wanted to explain why I
left it in.

Ed, what say you?  Others?

-MSK

--f46d04138c9f3f32e60508bc6c07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Casey,<br><br>On Tue, Nov 25, 2014 at 7:30 PM, Casey De=
ccio <span dir=3D"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_b=
lank">casey@deccio.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div><span class=3D""></span>I recommended in my earlier comments (and st=
ill recommend) that the following sentence be removed, on the basis that it=
 can be said about any solution--even those produced by the proposed workin=
g group:<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div><br>&quot;When this list is inaccurate, it exposes a deviation from =
reality that
     =20
     =20
       =20
        degrades service to some and can be exploited by others.&quot;<br><=
/div></div></div></div></blockquote><div><br>I did see that comment but I l=
eft the sentence in.=C2=A0 In the context in=20
which it appears, I thought it added useful emphasis to the concern and=20
impetus for coming up with something better than a table maintained on a
 best-effort basis.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div>(The recommendation was probably lost in the noise; I didn&#39;=
t see any comments opposing it.)<br></div></div></div></div></blockquote><d=
iv><br></div><div>I didn&#39;t see anyone supporting it either... ;-)<br><b=
r></div><div>I&#39;m happy to go with consensus in the end, but I wanted to=
 explain why I left it in.<br><br></div><div>Ed, what say you?=C2=A0 Others=
?<br><br></div><div>-MSK<br></div></div></div></div>

--f46d04138c9f3f32e60508bc6c07--


From nobody Tue Nov 25 21:47:05 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887D11A1AAF for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 21:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPoXkBbOWsxq for <dbound@ietfa.amsl.com>; Tue, 25 Nov 2014 21:47:02 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669C91A0276 for <dbound@ietf.org>; Tue, 25 Nov 2014 21:47:02 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id rp18so2050071iec.39 for <dbound@ietf.org>; Tue, 25 Nov 2014 21:47:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SgBHfG6PHdQZwbdUIFLkqvkOWziXxiB7dt4fldP2B3I=; b=JFy1f+Sc/vkcZeLTlpCjNbZPYFHxCnerBYr1bhWLugAcdXoKye9M+z1y7WKtD4vZ+3 Qxg3MGStC/yEjPzJK+QG6b1h8M+TSawszAorMlaryo6TengpiQvXF6N8rdIIBRSvU420 huy70zsEzaiJpOmXGoFWgJ8MR+DVBiiUaF7rs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SgBHfG6PHdQZwbdUIFLkqvkOWziXxiB7dt4fldP2B3I=; b=GEoYcWcivUlbyFNKOSa/wjDvrNfcjSf/xFszrkFrg7Jmzh2+MbViuQLetRqxvVE9pw NFf9KrQAOA8JNXQX4ziy5mJsGhgQiqWlPpWC175uALsu6JtPji4xrtNUdYQVGi11MpLY Oxk1IbTAfecab92iPrnR0U8Zva6T4SIYqaY38rPMwV2asm81dGWlJuFUypEmmZl0ojCl V/4bdCB0ApqTWEVebkWyNy0oPLIr2lHGxv1nb9EeVN+Rep1chI+1kIoruOfxWlk9UDT5 evKy8eKy7J8EBc+WmziGL9kWaB4PoG271xLx1Jsm0jfBO7PDiIS39/pX27450p3JuvEa gZlw==
X-Gm-Message-State: ALoCoQkpgJNJopHirb9hWfDU5GErrZhnLIj+DRISHbIjQl+74sP5BPV69TljWkdnb7hEXJOAbN/r
MIME-Version: 1.0
X-Received: by 10.50.148.101 with SMTP id tr5mr7464228igb.12.1416980821481; Tue, 25 Nov 2014 21:47:01 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Tue, 25 Nov 2014 21:47:01 -0800 (PST)
In-Reply-To: <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com> <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
Date: Wed, 26 Nov 2014 00:47:01 -0500
Message-ID: <CAEKtLiR5VJiXH71QQwXXQUFSSAMeac7RNmJ0K80Zc7vpRh5dXg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134c7bc84a9820508bc8efc
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/oPav5Z_YgIQ85d6wh8VXkkaZYqE
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 05:47:03 -0000

--001a1134c7bc84a9820508bc8efc
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 26, 2014 at 12:37 AM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> I did see that comment but I left the sentence in.  In the context in
> which it appears, I thought it added useful emphasis to the concern and
> impetus for coming up with something better than a table maintained on a
> best-effort basis.
>
> ...
> I'm happy to go with consensus in the end, but I wanted to explain why I
> left it in.
>

Fair enough.  While I realize the intent was to identify shortcomings of
the existing solution, I felt this particular observation was unfairly
applied (only) to the PSL when it is in fact a more general shortcoming.
The softer sentence that alluded to, but didn't explicitly call out
problems such as this was: "Additionally, there are questions about the
scalability, central management, and third-party management of the PSL as
it currently exists."

That being said, this isn't a showstopper as far as I'm concerned, and
consensus opinion is good :)

Casey

--001a1134c7bc84a9820508bc8efc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 26, 2014 at 12:37 AM, Murray S. Kucherawy <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">=
superuser@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr">I did see that comment but I left the sentence in.=C2=A0 In=
 the context in=20
which it appears, I thought it added useful emphasis to the concern and=20
impetus for coming up with something better than a table maintained on a
 best-effort basis.<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div> <br></div></div></div></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>...<br></div><div>I&#39;m happy to go with consens=
us in the end, but I wanted to explain why I left it in.<br></div></div></d=
iv></div></blockquote><div><br></div><div>Fair enough.=C2=A0 While I realiz=
e the intent was to identify shortcomings of the existing solution, I felt =
this particular observation was unfairly applied (only) to the PSL when it =
is in fact a more general shortcoming.=C2=A0 The softer sentence that allud=
ed to, but didn&#39;t explicitly call out problems such as this was: &quot;=
Additionally, there are questions about the scalability, central management=
,
     =20
     =20
       =20
        and third-party management of the PSL as it currently exists.&quot;=
<br><br></div><div>That being said, this isn&#39;t a showstopper as far as =
I&#39;m concerned, and consensus opinion is good :)<br><br></div><div>Casey=
<br></div></div></div></div>

--001a1134c7bc84a9820508bc8efc--


From nobody Wed Nov 26 08:26:12 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D921A037A for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 08:26:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK58hwglQnxw for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 08:26:06 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778E81A0195 for <dbound@ietf.org>; Wed, 26 Nov 2014 08:26:06 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAQGQ1gV018754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Nov 2014 08:26:04 -0800
Message-ID: <5475FF08.9040809@dcrocker.net>
Date: Wed, 26 Nov 2014 08:25:44 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>, John Levine <johnl@taugh.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
In-Reply-To: <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 26 Nov 2014 08:26:04 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/yECW_hsbAsg7SZ2Ja82e84xKVzE
Cc: Suzanne Woolf <suzworldwide@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 16:26:10 -0000

On 11/25/2014 5:01 PM, Murray S. Kucherawy wrote:
> https://github.com/mskucherawy/docs/blob/master/charter-dbound

> dbound charter
> Various Internet protocols and applications require some mechanism for
> determining whether two Domain Name System (DNS) names are related. A

I thought there was agreement to say "Domain Names" and not "DNS", in
order to distinguish the administration of namespace assignments from
the operational query service that uses them.


> popular example is the need to determine whether example.com and
> foo.example.com are subject to the same administrative authority. To

Might as well include the example of 'seemingly unrelated' names here,
as well.  SO:

   foo.example.com are subject
   ->
   foo.example.com, or even example.net, are subject


> humans, the answer to this may be obvious. However, the DNS does not
> currently provide the ability to mark these sorts of relationships, which
> makes them impossible to discern with simple programming. For example,

the sentence is a bit awkward. to simplify:

   relationships, which...programming
   ->
   relationships.  This makes it impossible to discern relationships
   algorithmically.


> the right answer is not always "compare the rightmost two labels".
> The particular issue is that there is policy structure imposed by

"policy structure"?  That has a nice sound to it, but I doubt it will
have obvious and consistent meaning to a broad base of readers.

Perhaps:

   The particular issue is that applications and organizations impose
policies and procedures that create additional structure in their use of
domain names.  This creates many possible relationships that are not
evident in the names themselves or in the operational, public
representation of the names.


> organizations and by the domain name registration system that is independent
> of the architecture and protocol upon which the DNS is built. Historically,
> solutions for identifying relationships between domain names have been based
> almost exclusively on the DNS namespace and protocol. While this basis is

'almost exclusively on...'?  This sentence (and section of text) is far
too cryptic.  It needs an explicit reference.


> often sufficient, the fact that it relies on assumptions stemming from the
> nature of the DNS makes such solutions unreliable and unnecessarily

I thought the most popular mechanism was a manually-maintained table.
That doesn't really have any 'assumptions' to it.  And I don't know what
other mechanisms there are, nor what their assumptions are.


> constrained. For example, confirming or dismissing a relationship between
> two domain names based on the existence of a zone cut or common ancestry is
> often unfounded.
> For the purposes of this work, domain names are approached as identifiers
> used in other services, and not as DNS names in themselves. The working group

I believe this statement is simply incorrect.  The 'identifiers' are
domain names.  They are used as domain names.

The work intended here can be characterized as adding a layer of
relational 'structure' to domain names, without changing any of the
underlying domain name administration (or any of the associated
operational service.)


> is not chartered to do any work on management of the DNS itself; the work
> here is entirely focused on the DNS namespace, and not the DNS protocol. The
> structure of the DNS and the administrative boundaries in the DNS are
> thus entirely out of scope for the working group.
> Currently, the most well known solution in existence is the Public Suffix
> List (PSL). The PSL is maintained by a Web browser producer and is kept
> current by volunteers on a best-effort basis. It contains a list of points
> in the DNS tree at which registrations take place and is used to identify
> the boundary between so-called "public" names (below which registrations
> can occur) and the private names (i.e., registered names) below them.
> When this list is inaccurate, it exposes a deviation from reality that
> degrades service to some and can be exploited by others. Being the de
> facto resource, and lacking a more comprehensive, alternative solution for
> relationship identification, the functionality of the PSL has often been
> misused to accomplish means beyond its capabilities. For example, there
> is no way to confirm the relationship between two domain names, only
> signal that there is or is not a public boundary between the two.
> Additionally, there are questions about the scalability, central management,
> and third-party management of the PSL as it currently exists.
> In terms of specific use cases: Within the realm of email, there is a
> desire to link an arbitrary fully-qualified domain name (FQDN) to the
> organizational domain name (traditionally in the namespace above it),

While it's good that the term org domain is being used, it needs more
definition, since some readers of the charter won't know what it means.
That's why I gave a working definition in the text a posted.

Also, the addition of "traditionally" here is interesting.  Is there a
view that an organizational domain is not always somewhere directly up
the branch?  I don't recall hearing this before.


> in order to identify a deterministic location where some sort of statement
> of policy regarding that domain name can be found. With respect to the

'that domain name' is unfortunately ambiguous.  The sentence contains
two references to domain name.  In fact, I'm not sure which is meant to
be referenced here.


> web, there is a similar need to identify relationships between different
> FQDNs, currently accomplished by comparing ancestries. However, there
> is also desire to reliably identify relationships outside of the realm
> and constraints of the DNS namespace tree.

   DNS -> Domain Name


> Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
> current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
> benefit from having this capability.
> The DBOUND working group will develop one or more solutions to this family
> of problems. If possible, a unified solution will be developed. However,
> the working group may discover that the email, web, equivalence, and
> possibly other problems require independent solutions, in which case the
> working group will follow that path. The solutions may or may not involve
> changes to the DNS, such as creation of new resource record types; in any
> case, all such changes will be incremental only.

Hmmm.  "changes to the DNS"?  Is that really meant, given the 'domain
name'/DNS distinction?


> This working group will not seek to amend the consuming protocols themselves
> (i.e., any web or mail standards) without rechartering, and only after
> completion of the base work. Any such work undertaken in parallel will
> eeed to be done as individual or independent submissions, or in another
> working group.




-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Wed Nov 26 09:04:29 2014
Return-Path: <casey@deccio.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2C21A1A30 for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 09:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD0n7HhzkBrq for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 09:04:26 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD391A1A31 for <dbound@ietf.org>; Wed, 26 Nov 2014 09:04:26 -0800 (PST)
Received: by mail-ig0-f177.google.com with SMTP id z20so2915597igj.16 for <dbound@ietf.org>; Wed, 26 Nov 2014 09:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J8KjyX+vQnFvJD+arJAyK5qtFHXur259nV8e1gk0+fM=; b=f9VF+1eBZldLW1yXn0CIWwtLz3pzGbxTlfNalqTILdnEfCClRoQae8isXcrwSx8rVH u7bdWn1v17ynHeBifaSUW8lrm80Hc+wOatb914CTfbtxaLfpzxnfpchgwcd+CWahg6OC 2H4j2Y7mZa4/LBP3+P3t++sF/Rc60o8hV38KM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J8KjyX+vQnFvJD+arJAyK5qtFHXur259nV8e1gk0+fM=; b=CJZHPeHvRglG9kC0IVMKP5KHFZo68h6quCRdpdvXpl+qPsjR8fyCwf8fe8VaYlbaCN 8sohFDTy/7FLXm5a8cit/njrnrnlDZ7oIO9wwrVUgFqOY3dmdNcTb4YYkdP2bQo61MZ5 MbQLD1kZuurGs9NcOZ18I9FUFT45oXbVxFBd4wkuCMMLCY3mtHhHXdrS8KdvOSFxayki YtwRE0/U7SCu+uup8FzfwEgfQJ6gx+bhACu9n4QABigH5zauwklqUFFhknuxwoqiPKna gGxeIq8bX6wGetozG7HP9Ix1Kf2hxJTzhvQ0eYKHtuyT/JtCKoGWMm+sBJHNNpEEes5P u5Qw==
X-Gm-Message-State: ALoCoQlyvcu3mcC13SBcrVpWf68HVomUSlsWqM7fSpNoECZLVEgJn1ULi6b/oTYM9gni8ug6hraY
MIME-Version: 1.0
X-Received: by 10.107.46.29 with SMTP id i29mr29488196ioo.73.1417021463936; Wed, 26 Nov 2014 09:04:23 -0800 (PST)
Received: by 10.50.108.107 with HTTP; Wed, 26 Nov 2014 09:04:23 -0800 (PST)
In-Reply-To: <5475FF08.9040809@dcrocker.net>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net>
Date: Wed, 26 Nov 2014 12:04:23 -0500
Message-ID: <CAEKtLiRwenOuyKmZuOdrkxVdLmkzBmGnaSad6cndx6tLrZ5Dog@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary=001a113703b4ff596a0508c60482
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/6MQiX3umnolmq6PX_kmfpxFkxDA
Cc: John Levine <johnl@taugh.com>, Suzanne Woolf <suzworldwide@gmail.com>, "Murray S. Kucherawy" <superuser@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 17:04:28 -0000

--001a113703b4ff596a0508c60482
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 26, 2014 at 11:25 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> > organizations and by the domain name registration system that is
> independent
> > of the architecture and protocol upon which the DNS is built.
> Historically,
> > solutions for identifying relationships between domain names have been
> based
> > almost exclusively on the DNS namespace and protocol. While this basis is
>
> 'almost exclusively on...'?  This sentence (and section of text) is far
> too cryptic.  It needs an explicit reference.
>

"relied primarily on..." is probably better text for that, especially since
(as you point out below), the usage is ubiquitous but not exclusive.


>
> > often sufficient, the fact that it relies on assumptions stemming from
> the
> > nature of the DNS makes such solutions unreliable and unnecessarily
>
> I thought the most popular mechanism was a manually-maintained table.
>

The PSL still relies on DNS namespace.  It identifies the (so-called)
public/private boundaries in the namespace, and the applications use
namespace in conjunction with that delineation to determine policy.


> That doesn't really have any 'assumptions' to it.  And I don't know what
> other mechanisms there are, nor what their assumptions are.
>
>
The illustration of the assumptions (and the one you commented on above) is
provided in the following sentence, which you quote below.


>
> > constrained. For example, confirming or dismissing a relationship between
> > two domain names based on the existence of a zone cut or common ancestry
> is
> > often unfounded.
> > For the purposes of this work, domain names are approached as identifiers
> > used in other services, and not as DNS names in themselves. The working
> group
>
> I believe this statement is simply incorrect.  The 'identifiers' are
> domain names.  They are used as domain names.
>
>
Maybe you want to say:

"... used in other services, independent of the DNS protocol and
infrastructure."

> In terms of specific use cases: Within the realm of email, there is a
> > desire to link an arbitrary fully-qualified domain name (FQDN) to the
> > organizational domain name (traditionally in the namespace above it),
>
> While it's good that the term org domain is being used, it needs more
> definition, since some readers of the charter won't know what it means.
> That's why I gave a working definition in the text a posted.
>

Note that the rest of the sentence provides some context here (i.e.,
referring to organizational policy).  However, if that is still
insufficient, here's a possible rewrite:

...desire to link an arbitrary fully-qualified domain name (FQDN) to its
organizational domain name (traditionally in the namespace above it), from
which its policy is inherited and may be retrieved from a deterministic
location.


> Also, the addition of "traditionally" here is interesting.  Is there a
> view that an organizational domain is not always somewhere directly up
> the branch?  I don't recall hearing this before.
>

I think this is in reference to the fact that there is some desire/demand
to signal/identify cross-domain relationships (i.e., outside the DNS
namespace hierarchy), which might apply to email or some other application.


>
>
> > in order to identify a deterministic location where some sort of
> statement
> > of policy regarding that domain name can be found. With respect to the
>
> 'that domain name' is unfortunately ambiguous.  The sentence contains
> two references to domain name.  In fact, I'm not sure which is meant to
> be referenced here.
>

With the (possible) rewrite above, this is helped.  Alternatively, throwing
in "organizational" before domain name helps clarify.

Casey

--001a113703b4ff596a0508c60482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 26, 2014 at 11:25 AM, Dave Crocker <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcro=
cker.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; organiz=
ations and by the domain name registration system that is independent<br>
&gt; of the architecture and protocol upon which the DNS is built. Historic=
ally,<br>
&gt; solutions for identifying relationships between domain names have been=
 based<br>
&gt; almost exclusively on the DNS namespace and protocol. While this basis=
 is<br>
<br>
&#39;almost exclusively on...&#39;?=C2=A0 This sentence (and section of tex=
t) is far<br>
too cryptic.=C2=A0 It needs an explicit reference.<br></blockquote><div><br=
></div><div>&quot;relied primarily on...&quot; is probably better text for =
that, especially since (as you point out below), the usage is ubiquitous bu=
t not exclusive.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
<br>
&gt; often sufficient, the fact that it relies on assumptions stemming from=
 the<br>
&gt; nature of the DNS makes such solutions unreliable and unnecessarily<br=
>
<br>
I thought the most popular mechanism was a manually-maintained table.<br></=
blockquote><div><br></div><div>The PSL still relies on DNS namespace.=C2=A0=
 It identifies the (so-called) public/private boundaries in the namespace, =
and the applications use namespace in conjunction with that delineation to =
determine policy.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
That doesn&#39;t really have any &#39;assumptions&#39; to it.=C2=A0 And I d=
on&#39;t know what<br>
other mechanisms there are, nor what their assumptions are.<br>
<br></blockquote><div><br></div><div>The illustration of the assumptions (a=
nd the one you commented on above) is provided in the following sentence, w=
hich you quote below. <br>=C2=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
<br>
&gt; constrained. For example, confirming or dismissing a relationship betw=
een<br>
&gt; two domain names based on the existence of a zone cut or common ancest=
ry is<br>
&gt; often unfounded.<br>
<span>&gt; For the purposes of this work, domain names are approached as id=
entifiers<br>
&gt; used in other services, and not as DNS names in themselves. The workin=
g group<br>
<br>
</span>I believe this statement is simply incorrect.=C2=A0 The &#39;identif=
iers&#39; are<br>
domain names.=C2=A0 They are used as domain names.<br>
<br></blockquote><div><br></div><div>Maybe you want to say:<br><br>&quot;..=
. <span>used in other services, independent of the DNS protocol and infrast=
ructure.&quot;<br></span><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><span>
</span>&gt; In terms of specific use cases: Within the realm of email, ther=
e is a<br>
&gt; desire to link an arbitrary fully-qualified domain name (FQDN) to the<=
br>
&gt; organizational domain name (traditionally in the namespace above it),<=
br>
<br>
While it&#39;s good that the term org domain is being used, it needs more<b=
r>
definition, since some readers of the charter won&#39;t know what it means.=
<br>
That&#39;s why I gave a working definition in the text a posted.<br></block=
quote><div><br></div><div>Note that the rest of the sentence provides some =
context here (i.e., referring to organizational policy).=C2=A0 However, if =
that is still insufficient, here&#39;s a possible rewrite: <br></div><div><=
br>...desire to link an arbitrary fully-qualified domain name (FQDN) to its=
 organizational domain name (traditionally in the namespace above it), from=
 which its policy is inherited and may be retrieved from a deterministic lo=
cation.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, the addition of &quot;traditionally&quot; here is interesting.=C2=A0 =
Is there a<br>
view that an organizational domain is not always somewhere directly up<br>
the branch?=C2=A0 I don&#39;t recall hearing this before.<br></blockquote><=
div><br></div><div>I think this is in reference to the fact that there is s=
ome desire/demand to signal/identify cross-domain relationships (i.e., outs=
ide the DNS namespace hierarchy), which might apply to email or some other =
application.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
<br>
<br>
&gt; in order to identify a deterministic location where some sort of state=
ment<br>
&gt; of policy regarding that domain name can be found. With respect to the=
<br>
<br>
&#39;that domain name&#39; is unfortunately ambiguous.=C2=A0 The sentence c=
ontains<br>
two references to domain name.=C2=A0 In fact, I&#39;m not sure which is mea=
nt to<br>
be referenced here.<br></blockquote><div><br></div><div>With the (possible)=
 rewrite above, this is helped.=C2=A0 Alternatively, throwing in &quot;orga=
nizational&quot; before domain name helps clarify.<br></div><div><br></div>=
<div>Casey<br></div></div></div></div>

--001a113703b4ff596a0508c60482--


From nobody Wed Nov 26 10:33:47 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426A51A1A91 for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 10:33:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT3oa0-l9QZT for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 10:33:42 -0800 (PST)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E889D1A1A6B for <dbound@ietf.org>; Wed, 26 Nov 2014 10:33:41 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id l15so13464326wiw.14 for <dbound@ietf.org>; Wed, 26 Nov 2014 10:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=She+lH/rob5tVFTf0Lnm4S2/v3CTvABX8iO5Ag1QtaI=; b=ecHNgl+eeHP/Ww9j5HK1OyZeN6ABiTqp3jNXZ4R3KlhKqX+6p5KMUknMAaE1yU0mkp wg29to9iCWoWisjZ4v5J6dW1OfYbszN4LSHgLDCKWP6ZJGwPPsiKPZ52IZvmC3WKz2JA bbMoGi0AhX5TnSKYr9iXFcrViYIW/Z4sFiJji2SdX53U6LQ3b/y2Y7wY727DMQwV7SNX YX52cwPQ0IDrrJ+oq3qTr+q+nhkAm1sQP7lQF4PvnmeLakFEEbGShvvODJ35/zxdfg4f ZUF6lPRY6J0KjMPU6MhMWuIQpeLHG+i62rCe/Ae1sZ1oreiLGoTL8imY0aHGCrKWuz4h Gm4w==
MIME-Version: 1.0
X-Received: by 10.194.103.232 with SMTP id fz8mr51914498wjb.110.1417026820782;  Wed, 26 Nov 2014 10:33:40 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Wed, 26 Nov 2014 10:33:40 -0800 (PST)
In-Reply-To: <5475FF08.9040809@dcrocker.net>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net>
Date: Wed, 26 Nov 2014 10:33:40 -0800
Message-ID: <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary=047d7bf109f04a45d30508c74425
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/-zBQrRzi6bdek6ZfabDG5iKtKgs
Cc: Suzanne Woolf <suzworldwide@gmail.com>, John Levine <johnl@taugh.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 18:33:45 -0000

--047d7bf109f04a45d30508c74425
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 26, 2014 at 8:25 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> > Various Internet protocols and applications require some mechanism for
> > determining whether two Domain Name System (DNS) names are related. A
>
> I thought there was agreement to say "Domain Names" and not "DNS", in
> order to distinguish the administration of namespace assignments from
> the operational query service that uses them.
>

Everywhere else in the charter, it does.  Here it's a mixture of "domain
names" and a first expansion of the acronym "DNS".  Do they not say the
same thing?


> > organizations and by the domain name registration system that is
> independent
> > of the architecture and protocol upon which the DNS is built.
> Historically,
> > solutions for identifying relationships between domain names have been
> based
> > almost exclusively on the DNS namespace and protocol. While this basis is
>
> 'almost exclusively on...'?  This sentence (and section of text) is far
> too cryptic.  It needs an explicit reference.
>

There are plenty of examples like SPF and DKIM/ADSP, and now DMARC, that
try to do this.  In fact I can't think of an example of a domain name
relationship scheme that is a valid counter example.  Anyone have a
suggestion?  DNAME perhaps?


> > often sufficient, the fact that it relies on assumptions stemming from
> the
> > nature of the DNS makes such solutions unreliable and unnecessarily
>
> I thought the most popular mechanism was a manually-maintained table.
> That doesn't really have any 'assumptions' to it.  And I don't know what
> other mechanisms there are, nor what their assumptions are.
>

We're not talking about the PSL here (yet), but rather previous attempts to
do the same thing using stuff like DNS tree-walks that we've ultimately
rejected (e.g., during the SSP discussions).


> > constrained. For example, confirming or dismissing a relationship between
> > two domain names based on the existence of a zone cut or common ancestry
> is
> > often unfounded.
> > For the purposes of this work, domain names are approached as identifiers
> > used in other services, and not as DNS names in themselves. The working
> group
>
> I believe this statement is simply incorrect.  The 'identifiers' are
> domain names.  They are used as domain names.
>
> The work intended here can be characterized as adding a layer of
> relational 'structure' to domain names, without changing any of the
> underlying domain name administration (or any of the associated
> operational service.)
>

This was Andrew's suggested text, and I believe he meant only to make it
clear we're not changing DNS protocol or infrastructure.


> While it's good that the term org domain is being used, it needs more
> definition, since some readers of the charter won't know what it means.
> That's why I gave a working definition in the text a posted.
>

I changed it to "registered" instead of "organizational" since we're really
talking about a name that appears in a domain name registry, and I'd rather
not import a definition from DMARC if it can be avoided.


> Also, the addition of "traditionally" here is interesting.  Is there a
> view that an organizational domain is not always somewhere directly up
> the branch?  I don't recall hearing this before.
>

That's in reference to John's (or Kurt's?) point that google.com might want
to express a policy that also covers youtube.com without having to put a
policy record in both places.


> > web, there is a similar need to identify relationships between different
> > FQDNs, currently accomplished by comparing ancestries. However, there
> > is also desire to reliably identify relationships outside of the realm
> > and constraints of the DNS namespace tree.
>
>    DNS -> Domain Name
>

Removed "DNS" instead.


> > The DBOUND working group will develop one or more solutions to this
> family
> > of problems. If possible, a unified solution will be developed. However,
> > the working group may discover that the email, web, equivalence, and
> > possibly other problems require independent solutions, in which case the
> > working group will follow that path. The solutions may or may not involve
> > changes to the DNS, such as creation of new resource record types; in any
> > case, all such changes will be incremental only.
>
> Hmmm.  "changes to the DNS"?  Is that really meant, given the 'domain
> name'/DNS distinction?
>

I think this makes sense in the context of the rest of the sentence.  We're
only allowed to make incremental changes to the DNS, which as far as I can
imagine could only mean a new RRtype.

-MSK

--047d7bf109f04a45d30508c74425
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 26, 2014 at 8:25 AM, Dave Crocker <span dir=3D=
"ltr">&lt;<a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocke=
r.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">&gt; Various Internet protocols an=
d applications require some mechanism for<br>
&gt; determining whether two Domain Name System (DNS) names are related. A<=
br>
<br>
I thought there was agreement to say &quot;Domain Names&quot; and not &quot=
;DNS&quot;, in<br>
order to distinguish the administration of namespace assignments from<br>
the operational query service that uses them.<br></blockquote><div><br></di=
v><div>Everywhere else in the charter, it does.=C2=A0 Here it&#39;s a mixtu=
re of &quot;domain names&quot; and a first expansion of the acronym &quot;D=
NS&quot;.=C2=A0 Do they not say the same thing?<br>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
&gt; organizations and by the domain name registration system that is indep=
endent<br>
&gt; of the architecture and protocol upon which the DNS is built. Historic=
ally,<br>
&gt; solutions for identifying relationships between domain names have been=
 based<br>
&gt; almost exclusively on the DNS namespace and protocol. While this basis=
 is<br>
<br>
&#39;almost exclusively on...&#39;?=C2=A0 This sentence (and section of tex=
t) is far<br>
too cryptic.=C2=A0 It needs an explicit reference.<br></blockquote><div><br=
></div><div>There are plenty of examples like SPF and DKIM/ADSP, and now DM=
ARC, that try to do this.=C2=A0 In fact I can&#39;t think of an example of =
a domain name relationship scheme that is a valid counter example.=C2=A0 An=
yone have a suggestion?=C2=A0 DNAME perhaps?<br>=C2=A0<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
&gt; often sufficient, the fact that it relies on assumptions stemming from=
 the<br>
&gt; nature of the DNS makes such solutions unreliable and unnecessarily<br=
>
<br>
I thought the most popular mechanism was a manually-maintained table.<br>
That doesn&#39;t really have any &#39;assumptions&#39; to it.=C2=A0 And I d=
on&#39;t know what<br>
other mechanisms there are, nor what their assumptions are.<br></blockquote=
><div><br></div><div>We&#39;re not talking about the PSL here (yet), but ra=
ther previous attempts to do the same thing using stuff like DNS tree-walks=
 that we&#39;ve ultimately rejected (e.g., during the SSP discussions).<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
&gt; constrained. For example, confirming or dismissing a relationship betw=
een<br>
&gt; two domain names based on the existence of a zone cut or common ancest=
ry is<br>
&gt; often unfounded.<br>
<span class=3D"">&gt; For the purposes of this work, domain names are appro=
ached as identifiers<br>
&gt; used in other services, and not as DNS names in themselves. The workin=
g group<br>
<br>
</span>I believe this statement is simply incorrect.=C2=A0 The &#39;identif=
iers&#39; are<br>
domain names.=C2=A0 They are used as domain names.<br>
<br>
The work intended here can be characterized as adding a layer of<br>
relational &#39;structure&#39; to domain names, without changing any of the=
<br>
underlying domain name administration (or any of the associated<br>
operational service.)<br></blockquote><div><br></div><div>This was Andrew&#=
39;s suggested text, and I believe he meant only to make it clear we&#39;re=
 not changing DNS protocol or infrastructure.<br>=C2=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
While it&#39;s good that the term org domain is being used, it needs more<b=
r>
definition, since some readers of the charter won&#39;t know what it means.=
<br>
That&#39;s why I gave a working definition in the text a posted.<br></block=
quote><div><br></div><div>I changed it to &quot;registered&quot; instead of=
 &quot;organizational&quot; since we&#39;re really talking about a name tha=
t appears in a domain name registry, and I&#39;d rather not import a defini=
tion from DMARC if it can be avoided.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Also, the addition of &quot;traditionally&quot; here is interesting.=C2=A0 =
Is there a<br>
view that an organizational domain is not always somewhere directly up<br>
the branch?=C2=A0 I don&#39;t recall hearing this before.<br></blockquote><=
div><br></div><div>That&#39;s in reference to John&#39;s (or Kurt&#39;s?) p=
oint that <a href=3D"http://google.com">google.com</a> might want to expres=
s a policy that also covers <a href=3D"http://youtube.com">youtube.com</a> =
without having to put a policy record in both places.<br>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
&gt; web, there is a similar need to identify relationships between differe=
nt<br>
&gt; FQDNs, currently accomplished by comparing ancestries. However, there<=
br>
&gt; is also desire to reliably identify relationships outside of the realm=
<br>
&gt; and constraints of the DNS namespace tree.<br>
<br>
=C2=A0 =C2=A0DNS -&gt; Domain Name<br></blockquote><div><br></div><div>Remo=
ved &quot;DNS&quot; instead.<br>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
&gt; The DBOUND working group will develop one or more solutions to this fa=
mily<br>
&gt; of problems. If possible, a unified solution will be developed. Howeve=
r,<br>
&gt; the working group may discover that the email, web, equivalence, and<b=
r>
&gt; possibly other problems require independent solutions, in which case t=
he<br>
&gt; working group will follow that path. The solutions may or may not invo=
lve<br>
&gt; changes to the DNS, such as creation of new resource record types; in =
any<br>
&gt; case, all such changes will be incremental only.<br>
<br>
Hmmm.=C2=A0 &quot;changes to the DNS&quot;?=C2=A0 Is that really meant, giv=
en the &#39;domain<br>
name&#39;/DNS distinction?<br></blockquote><div><br></div><div>I think this=
 makes sense in the context of the rest of the sentence.=C2=A0 We&#39;re on=
ly allowed to make incremental changes to the DNS, which as far as I can im=
agine could only mean a new RRtype.<br><br></div><div>-MSK<br></div></div><=
/div></div>

--047d7bf109f04a45d30508c74425--


From nobody Wed Nov 26 13:39:54 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED601A1EF0 for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 13:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkIN5EcBgs-L for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 13:39:50 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B211A1EEB for <dbound@ietf.org>; Wed, 26 Nov 2014 13:39:50 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id r20so13886218wiv.6 for <dbound@ietf.org>; Wed, 26 Nov 2014 13:39:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+hLef+mgSQWDdQW+UPmcss8ZdwAP29m/ULQXen6OIso=; b=USTVaHGz3SNdQlONQ07Pjcv8Zz6JIwZ8yD3M00u3adhd69ITT5Yzh5DbcPr9JBNmL3 Qa5knKsCITC2q5A/vsnBIq2m4lK59GnhjKU4hk9KNWjHyMrnANjPctKTOKkQ2pgPViP3 nDQKBMMG1fyGq+3fGfR6iroQns3gb0t5QfyEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+hLef+mgSQWDdQW+UPmcss8ZdwAP29m/ULQXen6OIso=; b=NQW2z2u4Z4MMujKuZV64j+NKEwGBx6QZQDsLLaNHyxXtK+PMEj7BB8p/mCkDvwfoOE wa1yrsUKRB7xPtjPhvhV7hkiGVka9l7v1taZNPsfWI9cFdH2QY121Y+ZoxZRJhCvCwm1 c8udQEeHhsHixBffOzTsH9ifF1c5Yj0SvCjxeBlBBMOfhLXX+wZzhul9NHzW3AkH2SRI 6W1hLaT2Lgf3uXayun8CO+w+keRocHe54UXfrD44EOB3vvr89fronsbGShjxTS6I0Zdu JBwHK3aujk9ynVJU/BInWoYa6nLn+/fk5GtkYucvCZMYwj1Einj+yhQLWpnDTckeGCWD fnNA==
X-Gm-Message-State: ALoCoQlm2ko5mfaNhgoX191e1YsHRJGCHopSNl6ebjFSsP09ILhs8PxlpTAC/FwCFDdkpvPqoKD2
MIME-Version: 1.0
X-Received: by 10.180.8.102 with SMTP id q6mr43756856wia.72.1417037989014; Wed, 26 Nov 2014 13:39:49 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.194.188.115 with HTTP; Wed, 26 Nov 2014 13:39:48 -0800 (PST)
In-Reply-To: <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com> <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
Date: Wed, 26 Nov 2014 13:39:48 -0800
X-Google-Sender-Auth: zPZACNCGQvxw3jlbK5d11-oNUMo
Message-ID: <CABuGu1qvRrUbDCAYPpaxDdM6s16F1zUtXNraYk2oUadk6ycFzQ@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04440280f8062e0508c9dd82
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/ZJggA1GomtPEUSXQ9nCc4lNeJfg
Cc: Casey Deccio <casey@deccio.net>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 21:39:52 -0000

--f46d04440280f8062e0508c9dd82
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 25, 2014 at 9:37 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

>
> On Tue, Nov 25, 2014 at 7:30 PM, Casey Deccio <casey@deccio.net> wrote:
>
> I recommended in my earlier comments (and still recommend) that the
>> following sentence be removed, on the basis that it can be said about any
>> solution--even those produced by the proposed working group:
>>
>
>> "When this list is inaccurate, it exposes a deviation from reality that
>> degrades service to some and can be exploited by others."
>>
>
> I did see that comment but I left the sentence in.  In the context in
> which it appears, I thought it added useful emphasis to the concern and
> impetus for coming up with something better than a table maintained on a
> best-effort basis.
>
> I didn't see anyone supporting it either... ;-)
>

I'm in favor of the statement as a justification for the DBOUND work,
although maybe generalizing it to apply to the "overlay" that we are
working on (or any other), rather than the PSL exclusively would be
reasonable.

--Kurt

--f46d04440280f8062e0508c9dd82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Nov 25, 2014 at 9:37 PM, Murray S. Kucherawy <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">s=
uperuser@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D""><br>On Tue, Nov 25, 2014 at 7:30 PM, Casey Deccio <span dir=3D=
"ltr">&lt;<a href=3D"mailto:casey@deccio.net" target=3D"_blank">casey@decci=
o.net</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div><span></span>I recommended in my earlier comments (and st=
ill recommend) that the following sentence be removed, on the basis that it=
 can be said about any solution--even those produced by the proposed workin=
g group:<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div><br>&quot;When this list is inaccurate, it exposes a deviation from =
reality that
     =20
     =20
       =20
        degrades service to some and can be exploited by others.&quot;<br><=
/div></div></div></div></blockquote></span><div><br>I did see that comment =
but I left the sentence in.=C2=A0 In the context in=20
which it appears, I thought it added useful emphasis to the concern and=20
impetus for coming up with something better than a table maintained on a
 best-effort basis.<br></div><span class=3D""><div><br></div></span><div>I =
didn&#39;t see anyone supporting it either... ;-)<br></div></div></div></di=
v></blockquote><div>=C2=A0</div><div>I&#39;m in favor of the statement as a=
 justification for the DBOUND work, although maybe generalizing it to apply=
 to the &quot;overlay&quot; that we are working on (or any other), rather t=
han the PSL exclusively would be reasonable. <br><br></div><div>--Kurt<br><=
/div></div></div></div>

--f46d04440280f8062e0508c9dd82--


From nobody Wed Nov 26 16:31:36 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179781A020B for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 16:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkbtqUlDtyY2 for <dbound@ietfa.amsl.com>; Wed, 26 Nov 2014 16:31:32 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E731A00A2 for <dbound@ietf.org>; Wed, 26 Nov 2014 16:31:32 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAR0VR3V015447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Nov 2014 16:31:30 -0800
Message-ID: <547670CF.7040504@dcrocker.net>
Date: Wed, 26 Nov 2014 16:31:11 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net> <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com>
In-Reply-To: <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 26 Nov 2014 16:31:31 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/dqsy2to0581VTudQeGy-gZNSFBs
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Nov 2014 00:31:35 -0000

On 11/26/2014 10:33 AM, Murray S. Kucherawy wrote:
> On Wed, Nov 26, 2014 at 8:25 AM, Dave Crocker <dhc@dcrocker.net
> <mailto:dhc@dcrocker.net>> wrote:
> 
>     > Various Internet protocols and applications require some mechanism for
>     > determining whether two Domain Name System (DNS) names are related. A
> 
>     I thought there was agreement to say "Domain Names" and not "DNS", in
>     order to distinguish the administration of namespace assignments from
>     the operational query service that uses them.
> 
> Everywhere else in the charter, it does.  Here it's a mixture of "domain
> names" and a first expansion of the acronym "DNS".  Do they not say the
> same thing?

Nearly everybody -- possibly even including some DNS savants --
considers the naming scheme and the query service as a single entity.
Wikipedia, for example, introduces DNS as "a hierarchical distributed
naming system..."  I take the presence of "distributed" as referring to
the operational query mechanism.  As a namespace abstraction, domain
names are not 'distributed, though of course they very much are in terms
of the query service.  I think even the original RFCs are a bit casual
about the distinction.

As an exercise, randomly ask folk what they think "DNS" refers to.

Again, I'm working from Andrew's suggestion to decouple namespace from
query service operation.  (Which I think is a good idea.)  So the
charter has the challenge of helping readers avoid a common conflation.


>     > organizations and by the domain name registration system that is
>     independent
>     > of the architecture and protocol upon which the DNS is built.
>     Historically,
>     > solutions for identifying relationships between domain names have
>     been based
>     > almost exclusively on the DNS namespace and protocol. While this
>     basis is
> 
>     'almost exclusively on...'?  This sentence (and section of text) is far
>     too cryptic.  It needs an explicit reference.
> 
> 
> There are plenty of examples like SPF and DKIM/ADSP, and now DMARC, that
> try to do this.  In fact I can't think of an example of a domain name
> relationship scheme that is a valid counter example.  Anyone have a
> suggestion?  DNAME perhaps?

My suggestion is to make the nature of each example explicit.  If the
reader is not already expert in SPF or the rest, this will then give
them a specific tag for knowing what to go read about, within texts
about SPF, or the like.


>     > often sufficient, the fact that it relies on assumptions stemming
>     from the
>     > nature of the DNS makes such solutions unreliable and unnecessarily
> 
>     I thought the most popular mechanism was a manually-maintained table.
>     That doesn't really have any 'assumptions' to it.  And I don't know what
>     other mechanisms there are, nor what their assumptions are.
> 
> 
> We're not talking about the PSL here (yet), but rather previous attempts
> to do the same thing using stuff like DNS tree-walks that we've
> ultimately rejected (e.g., during the SSP discussions).

So, part of my confusion -- and possibly confusion of the text -- is
between what has actually been used -- however poorly, versus what has
merely been considered.


>     > constrained. For example, confirming or dismissing a relationship
>     between
>     > two domain names based on the existence of a zone cut or common
>     ancestry is
>     > often unfounded.
>     > For the purposes of this work, domain names are approached as identifiers
>     > used in other services, and not as DNS names in themselves. The working group
> 
>     I believe this statement is simply incorrect.  The 'identifiers' are
>     domain names.  They are used as domain names.
> 
>     The work intended here can be characterized as adding a layer of
>     relational 'structure' to domain names, without changing any of the
>     underlying domain name administration (or any of the associated
>     operational service.)
> 
> 
> This was Andrew's suggested text, and I believe he meant only to make it
> clear we're not changing DNS protocol or infrastructure.

If "not as DNS names in themselves" is supposed to mean "these are
domain names, but they are not being considered in terms of the query
service implementation", then -- as earlier -- I think the goal is fine.
 The problem is the wording.  It requires the reader to understand a
nuance of distinction that, I believe, is not commonly considered.

Perhaps:

   For the purposes of this work, domain names are approached
identifiers used by organizations and services, independent of any
underlying protocols or mechanisms.  Specifically, the work will not
propose any changes to DNS protocols.


> 
>     While it's good that the term org domain is being used, it needs more
>     definition, since some readers of the charter won't know what it means.
>     That's why I gave a working definition in the text a posted.
> 
> 
> I changed it to "registered" instead of "organizational" since we're
> really talking about a name that appears in a domain name registry, and
> I'd rather not import a definition from DMARC if it can be avoided.


The latest text:

  "desire to link an arbitrary fully-qualified domain name (FQDN) to the
   registered domain name (traditionally in the namespace above it),"

is now confusing.

'Registered' has a different and far broader meaning.  Except in very
unusual scenarios, all domain names -- and all parts of domain names --
are registered.  That's how they get assigned.

My original suggestion offered a self-contained definition of org
domain, so that no reference to dmarc would be needed.  And it defined
it in terms that described what is functionally salient, to distinguish
the org domain.


>     Also, the addition of "traditionally" here is interesting.  Is there a
>     view that an organizational domain is not always somewhere directly up
>     the branch?  I don't recall hearing this before.
> 
> 
> That's in reference to John's (or Kurt's?) point that google.com
> <http://google.com> might want to express a policy that also covers
> youtube.com <http://youtube.com> without having to put a policy record
> in both places.

See above.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Nov 27 06:34:01 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6057A1A8931 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 06:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level: 
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSaBy0S4m6El for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 06:33:57 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F264E1A892C for <dbound@ietf.org>; Thu, 27 Nov 2014 06:33:56 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 27 Nov 2014 06:33:55 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Thu, 27 Nov 2014 06:33:55 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
Thread-Index: AQHQCOFuocShnNveAUSxF0dwJFLekpxx5UUAgABzSgCAAAuogIAANSaAgAAEEoCAACmPAIAAI3oAgAHUYoA=
Date: Thu, 27 Nov 2014 14:33:54 +0000
Message-ID: <D09C9D16.753B%edward.lewis@icann.org>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com> <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
In-Reply-To: <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499925631_3090304"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/lz_sfB-1HHwO3M5jS0veZU4G0mM
Cc: Casey Deccio <casey@deccio.net>, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Nov 2014 14:34:00 -0000

--B_3499925631_3090304
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 11/26/14, 0:37, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

>Ed, what say you?  Others?

Meta-comment.

The comment by John Levine to not get too metaphysical comes back to
haunt.  Reading the traffic, a lot of it has given over to the split of
=E2=80=98namespace=E2=80=99 from =E2=80=98query system=E2=80=99 - to use one divide.  I think this =
is
important to cover but this shouldn=E2=80=99t be the stumbling block we should
trip over.  DBound ought to be about how applications treat the names or
identifiers.  The discussion is going over territory that I am sensitive
too, and is what I was trying to address.

An unoriginal comment.  (Kind of a remake of a Hollywood classic into a
3-D animated full length feature.)

Perhaps explicitly stating that this is about how applications rely (in
the sense of being relying parties) on domain names, or the way in which
applications manipulate domain names is needed.  My distaste for
mentioning domain names has ebbed because this is not the issue the group
needs to spend much energy on - it should be about the applications=E2=80=99
actions.

Suggestion to simplify the charter.

For the sake of the charter, I would rather de-emphasize the Public Suffix
List save to perhaps to produce a document describing it (as it is) and
with some analysis of why it is not a general purpose solution or model
for a general solution.  So I don=E2=80=99t think it is appropriate include the
comment "When this list is inaccurate, it exposes=E2=80=9D in the charter per se.
In other words, no need to bash work that someone else volunteered to do
under their own initiative.

A vacuous promise.

I=E2=80=99ll re-read the charter suggestion early next week as I=E2=80=99m waiting for =
the
parade to start on TV now. ;)  (US Thanksgiving.)  In the mean time, there
may be more bright ideas posted.





--B_3499925631_3090304
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQbgG5BM+frYmoFOdrA
cosWob7zMzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjcxNDMzNTFaMA0GCSqGSIb3DQEBAQUABIIBAA3ngTi7N9LTvRQFHKdhoRzTt5ii8A70hfIc
W0u/gSyTlz7JVxkYMXhDA7w8AE/XtxNactMdkHdOe/xmM7pmyUmokceFiDx5NLMtsUbxhu8n
lddKL1YHo0YW7nXmzNj/cEGS0kuiHaxKFNgCY2duQxY3AZWt9nQk7Lswan734S384gkWGtfg
xpPQnUhfkwwRtoBBVI+fFWcXjzncY4jHdwzgGVrrN5W3W7LF7BjgeOwAXCMNtZkSX/VRO+Le
A49MHirY+1kDhznA9St0wkw0OoKPeOKsqkJHbh0ljY4Jf2v14NyC3EKmtMogKKTQdQ74uUaI
QzbkzShIKNQcI0gOA4s=

--B_3499925631_3090304--


From nobody Thu Nov 27 08:15:32 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9121A00C0 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 08:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aQHii46iCz1 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 08:15:27 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632F11A00BD for <dbound@ietf.org>; Thu, 27 Nov 2014 08:15:27 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sARGFIAV018119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Nov 2014 08:15:22 -0800
Message-ID: <54774E05.1080205@dcrocker.net>
Date: Thu, 27 Nov 2014 08:15:01 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Edward Lewis <edward.lewis@icann.org>, "dbound@ietf.org" <dbound@ietf.org>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <CAEKtLiSAUr=+QinCQFAhcriko=PNz45yszM48iVfP9TzA_2L_A@mail.gmail.com> <CAL0qLwYqDyLcdWOJxJJCa1kKEJFo7DBmrs9ZmtMW2d==aL2hzA@mail.gmail.com> <D09C9D16.753B%edward.lewis@icann.org>
In-Reply-To: <D09C9D16.753B%edward.lewis@icann.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 27 Nov 2014 08:15:22 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/LRvg-e9qC4kih9jCbe-9H7y9BNk
Cc: Casey Deccio <casey@deccio.net>, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Nov 2014 16:15:29 -0000

On 11/27/2014 6:33 AM, Edward Lewis wrote:
> For the sake of the charter, I would rather de-emphasize the Public Suffix
> List save to perhaps to produce a document describing it (as it is) and
> with some analysis of why it is not a general purpose solution or model
> for a general solution.  So I don’t think it is appropriate include the
> comment "When this list is inaccurate, it exposes” in the charter per se.
> In other words, no need to bash work that someone else volunteered to do
> under their own initiative.


There is a small set of prior work, relevant to the proposed work.  A
charter should make 'useful' reference to that work, in order to
establish a context for the proposed work.

IMO, 'useful' means it should cite the prior work and give some sense of
what it is and how it has not been sufficient or how it points to
needing the current work.  This certainly must not represent bashing,
but needs to motivate the current work.  It needs to give enough
reference so that a motivated reader knows where to go for more
information and what to look for.

Ultimately a reader should be able to know why the proposed work is
worth the considerable cost it will incur.  (Typical IETF standards cost
the community considerably more than US$ 1M and typically a significant
multiple.)  Knowing 'why' is different from knowing 'what' the proposed
work is.

Setting the context not only justifies the proposed work; it constrains
it, by making clear the nature of the need, in a community sense.  It
can help limit "here's a nifty feature I like" in favor of "here's an
essential feature the community needs."

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Nov 27 12:11:47 2014
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433621A01AE for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 12:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level: 
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1oNDX7vMBa9 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 12:11:44 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BE81A01A8 for <dbound@ietf.org>; Thu, 27 Nov 2014 12:11:43 -0800 (PST)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DFE088A035 for <dbound@ietf.org>; Thu, 27 Nov 2014 20:11:42 +0000 (UTC)
Date: Thu, 27 Nov 2014 15:11:42 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20141127201142.GJ9228@mx1.yitter.info>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/r1FtBhYnyrfW-Z5AxoTKRz5CAlo
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Nov 2014 20:11:45 -0000

On Tue, Nov 25, 2014 at 05:01:43PM -0800, Murray S. Kucherawy wrote:
> 
> So how's it look now?

I think it's in good shape, and I'd like to suggest that we've been
staring at it long enough that small differences may loom large to us
and be irrelevant to others.  So I suggest we put it out for comment
either by relevant ADs (I think this is apps and sec, though I'm
prepared to be convinced of ops), or by appsawg and saag, or both.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Thu Nov 27 17:29:46 2014
Return-Path: <kambe@jprs.co.jp>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857E01A03A3 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 17:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.497
X-Spam-Level: **
X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZZEHeOZkBfM for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 17:29:43 -0800 (PST)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C2B1A03A4 for <dbound@ietf.org>; Thu, 27 Nov 2014 17:29:43 -0800 (PST)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id sAS1Tb0u015122; Fri, 28 Nov 2014 10:29:37 +0900
X-AuditID: ac120820-b7f318e000000deb-6b-5477d0014220
Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 92.83.03563.100D7745; Fri, 28 Nov 2014 10:29:37 +0900 (JST)
Date: Fri, 28 Nov 2014 10:29:18 +0900 (JST)
Message-Id: <20141128.102918.104035934.kambe@jprs.co.jp>
To: superuser@gmail.com
From: Naoki Kambe <kambe@jprs.co.jp>
In-Reply-To: <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com>
References: <20141125171648.GK5479@mx1.yitter.info> <5474BACF.9030307@dcrocker.net> <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com>
Organization: Japan Registry Services Co., Ltd.
X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsWyRoiFT5fxQnmIwZUdqha7Ll9jt5j4vYHN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4feAaU8EJtoqNfc/YGxjnsnYxcnJICJhI 7Pw9iRHCFpO4cG89WxcjF4eQwElGibXvZrKAJFgEtCUmX9sE1sArYCHx4uVBpi5GDg4RAXGJ K5eMQcLMAsIS7569AisXFlCRaL00ix3EZgOyl93bDFbOKRAo8ft+IsT4OYwSG+dcYQOJ8wvo S0xtSoE4wU6i6e87FpAwr4CgxN8dwhDTtSR6Zjxmh7DlJba/ncM8gVFgFkLVLCRVs5BULWBk XsUok5+WplucmpdSnJtuYKhXUpmvl1VQVKyXDKI3MYKDk0NhB+OMUwaHGAU4GJV4eF8eKQsR Yk0sK67MPcQoycGkJMp7/0h5iBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXq+TQDnelMTKqtSi fJiUNAeLkjgvs3FvsJBAemJJanZqakFqEUxWhoNDSYJ36TmgRsGi1PTUirTMnBKENBMHJ8hw HqDhjSA1vMUFibnFmekQ+VOMqhwtTW97mYRY8vLzUqXEeb1AigRAijJK8+DmvGIUB3pHmJf9 PFCWB5iA4Ca8AhrOBDRcbGopyPCSRISUVANjkpxwjOJZie79sieOH9Fc8uKxepNudFfV3Hsi FccnXdnyX+TdlDVvbr81eN084//6cyfmdRx8qM+y0CeW+9jt7XoTlrC8jNp2v8TATHil8J2G jnk9vRwZt+dmtb/6u+u6kcNvwQCTxZcYjQU3/+MpUaqb7sa1Rrz7vm3bSeWqWVXvt8Ua/JV5 o8RSnJFoqMVcVJwIAHTfqM79AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/hZBJDzMz3qKB6dWO78mwpvc2iv4
Cc: dbound@ietf.org
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 01:29:44 -0000

Hi,

I have a couple of general questions about the draft charter.

> The DBOUND working group will develop one or more solutions to this family
> of problems.  If possible, a unified solution will be developed.  However,
> the working group may discover that the email, web, equivalence, and
> possibly other problems require independent solutions, in which case the
> working group will follow that path.  The solutions may or may not involve
> changes to the DNS, such as creation of new resource record types; in any
> case, all such changes will be incremental only.

What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?

What is the scope of this WG?  For example, is an interoperability
test using the solutions between a web server and a web browser
included in its scope?

Regards,
Naoki Kambe


From nobody Thu Nov 27 23:06:11 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C9C1A1A58 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 23:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBnyDmE2FLa1 for <dbound@ietfa.amsl.com>; Thu, 27 Nov 2014 23:06:06 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427FB1A1A54 for <dbound@ietf.org>; Thu, 27 Nov 2014 23:06:06 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id n3so10238475wiv.13 for <dbound@ietf.org>; Thu, 27 Nov 2014 23:06:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xDzvr4ZCeqnEalTcjzCZYPt/40/GlRQsS88tUnwK3Vo=; b=tjKVhNOIkrtxGyQpPyvxofwwpdDD441Ea1S7U7W2zSTyp+6Rjg/MQDG0MvvfuQ8ord A6SFJS6Zwxclo00VPwP4iC8P/rU3FTAK0zTCBVvffmd+/pXKrHlIKekNGeS4oRoptN9h tapr15FddxIadVWdDdWRYMuKfGJNXD980xJjnHJq+7h4MrIklSTDS5s5FFSMae1Byk7T wfZB8U43D0z03rUfgGxGYVKrlS2YS49+lvRU/fg7jWEFWNebhcXMeCpHZO9ggX/JJrFk 2F2og2auPAzfFDtT/hNYKOB6UZkdc7JsEEw9Lw0ItKIBZZJ8F3jpmODIbSImwdDjRmIU mxuQ==
MIME-Version: 1.0
X-Received: by 10.194.62.76 with SMTP id w12mr47748557wjr.5.1417158364894; Thu, 27 Nov 2014 23:06:04 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Thu, 27 Nov 2014 23:06:04 -0800 (PST)
In-Reply-To: <20141128.102918.104035934.kambe@jprs.co.jp>
References: <20141125171648.GK5479@mx1.yitter.info> <5474BACF.9030307@dcrocker.net> <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com> <20141128.102918.104035934.kambe@jprs.co.jp>
Date: Thu, 27 Nov 2014 23:06:04 -0800
Message-ID: <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Naoki Kambe <kambe@jprs.co.jp>
Content-Type: multipart/alternative; boundary=047d7ba977a4ee1b450508e5e4f2
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/Z5QVz8k3whK_Q3ki882NYl8Yrj0
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 07:06:08 -0000

--047d7ba977a4ee1b450508e5e4f2
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 27, 2014 at 5:29 PM, Naoki Kambe <kambe@jprs.co.jp> wrote:

> What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?
>

Could be either, I imagine.


> What is the scope of this WG?  For example, is an interoperability
> test using the solutions between a web server and a web browser
> included in its scope?
>

We could include such a thing if people think it might be useful, but I
can't imagine it being a requirement.

-MSK

--047d7ba977a4ee1b450508e5e4f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Nov 27, 2014 at 5:29 PM, Naoki Kambe <span dir=3D"=
ltr">&lt;<a href=3D"mailto:kambe@jprs.co.jp" target=3D"_blank">kambe@jprs.c=
o.jp</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">What does DBOUND stand for?=C2=A0 D=
ns BOUNDaries?=C2=A0 Domain name BOUNDaries?<br></blockquote><div><br></div=
><div>Could be either, I imagine.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
What is the scope of this WG?=C2=A0 For example, is an interoperability<br>
test using the solutions between a web server and a web browser<br>
included in its scope?<br></blockquote><div><br></div><div>We could include=
 such a thing if people think it might be useful, but I can&#39;t imagine i=
t being a requirement.<br><br></div><div>-MSK <br></div></div></div></div>

--047d7ba977a4ee1b450508e5e4f2--


From nobody Fri Nov 28 01:43:03 2014
Return-Path: <kambe@jprs.co.jp>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED23D1A1AE7 for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 01:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level: 
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC2YKVdbWn2u for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 01:43:01 -0800 (PST)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC861A1AC6 for <dbound@ietf.org>; Fri, 28 Nov 2014 01:43:00 -0800 (PST)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id sAS9gwd8032761 for <dbound@ietf.org>; Fri, 28 Nov 2014 18:42:58 +0900
X-AuditID: ac120820-b7f318e000000deb-23-547843a24792
Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 36.06.03563.2A348745; Fri, 28 Nov 2014 18:42:58 +0900 (JST)
Date: Fri, 28 Nov 2014 18:42:58 +0900 (JST)
Message-Id: <20141128.184258.104069774.kambe@jprs.co.jp>
To: dbound@ietf.org
From: Naoki Kambe <kambe@jprs.co.jp>
In-Reply-To: <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com>
References: <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com> <20141128.102918.104035934.kambe@jprs.co.jp> <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com>
Organization: Japan Registry Services Co., Ltd.
X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsWyRoiFT3eRc0WIwcxDKha7Ll9jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpnXu5gL9rBWPNowgbGBcR1LFyMHh4SAicSq7uguRk4gU0zi wr31bF2MXBxCAicZJWb8+skIkmAR0JZo/dLMDGLzClhIPPt1mQnEFhEQljh15gEbiC0soCLR emkWO4jNBmQvu7cZrIZTIFDiZu8pqKHHGCV+HJ/LDLKYX0BfYmpTCsRiO4mmv+/A7uEVEJT4 u0MYJMwsoCXRM+MxO4QtL7H97RzmCYz8sxCqZiGpmoWkagEj8ypGmfy0NN3i1LyU4tx0A0O9 ksp8vayComK9ZBC9iREcchwKOxhnnDI4xCjAwajEwxvJUREixJpYVlyZe4hRkoNJSZT3ujlQ iC8pP6UyI7E4I76oNCe1+BCjBAezkgjvqa/lIUK8KYmVValF+TApaQ4WJXFeZuPeYCGB9MSS 1OzU1ILUIpisDAeHkgSvjxPQUMGi1PTUirTMnBKENBMHJ8hwHqDhviA1vMUFibnFmekQ+VOM qhwtTW97mYRY8vLzUqXEeYVAigRAijJK8+DmvGIUB3pHmDcKJMsDTCtwE14BDWcCGi42tRRk eEkiQkqqgdFV93bVuwXfpq74P0kmMa6zJ3npDzv7yft+2q5U+mfAG/zy6go9nSXtL+emSiv2 /F/dntKw3GDhjU0ml9NZDvZUr1R63pz1yG69zeU57WJtZTs70nfP7/494Wav3borNcbZX4U+ rn2anlqyIabWfNK+sKRp0WdmCYmsfC2+XtHHa0ejx9PoH1pKLMUZiYZazEXFiQCEXqKD6AIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4Z1SV7y_EERKpSCJlexIVLhd964
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 09:43:02 -0000

From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 27 Nov 2014 23:06:04 -0800
> > What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?
> Could be either, I imagine.

As other proposal, "Domain administrative namespace BOUNDaries"?

> > What is the scope of this WG?  For example, is an interoperability
> > test using the solutions between a web server and a web browser
> > included in its scope?
> We could include such a thing if people think it might be useful, but I
> can't imagine it being a requirement.

I personally think someone should validate that the new solutions are
workable.  Whether or not the working group does.

Regards,
Naoki Kambe


From nobody Fri Nov 28 06:03:54 2014
Return-Path: <edward.lewis@icann.org>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ECA1A1B0A for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 06:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWe9YUUrncTn for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 06:03:49 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037451A1A6D for <dbound@ietf.org>; Fri, 28 Nov 2014 06:03:49 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 28 Nov 2014 06:03:47 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 28 Nov 2014 06:03:46 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: [Dbound] Sketch charter
Thread-Index: AQHQCBSr7gqlyJktkEiFvvJMtfoiO5xyG/OAgAABMACAAAGPgIAAAi8AgAOqhgCAAF4XAIAAK9cA///1CIA=
Date: Fri, 28 Nov 2014 14:03:46 +0000
Message-ID: <D09DE955.7598%edward.lewis@icann.org>
References: <CAL0qLwZeJKYiuUZAJwsMz9pfan_Ku=FgfZMjahTvsCna8vQ_yA@mail.gmail.com> <20141128.102918.104035934.kambe@jprs.co.jp> <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com> <20141128.184258.104069774.kambe@jprs.co.jp>
In-Reply-To: <20141128.184258.104069774.kambe@jprs.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3500010224_3589546"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/sD1--yLycyVJifDN9Hq9Jd472nU
Cc: Naoki Kambe <kambe@jprs.co.jp>
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 14:03:52 -0000

--B_3500010224_3589546
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

On 11/28/14, 4:42, "Naoki Kambe" <kambe@jprs.co.jp> wrote:

>From: "Murray S. Kucherawy" <superuser@gmail.com>
>Date: Thu, 27 Nov 2014 23:06:04 -0800
>> > What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?
>> Could be either, I imagine.
>
>As other proposal, "Domain administrative namespace BOUNDaries"?

Historically the names of Working Groups are not reliable indicators of
the work being done.  I.e., what DBOUND stands for is unimportant at this
stage, defining the WG=E2=80=99s scope is.  Later we can make DBOUND mean
something - or not.

What I mean to express - don=E2=80=99t let the name confine you to what should be
done.


>> > What is the scope of this WG?  For example, is an interoperability
>> > test using the solutions between a web server and a web browser
>> > included in its scope?
>> We could include such a thing if people think it might be useful, but I
>> can't imagine it being a requirement.
>
>I personally think someone should validate that the new solutions are
>workable.  Whether or not the working group does.

Again historically the IETF does not get (very) involved in developing
test or validation suites.  I=E2=80=99m not saying this is a good thing or not,
just =E2=80=98historically.=E2=80=99

The IETF is more of =E2=80=9Cthe idea person=E2=80=9D leaving the realities of getting
things to work to the operators.  ;) Outside of the IETF there are people
that stand up test or visualization tools for protocols.  It would be good
to have testable descriptions of the solutions in the RFCs, but sometimes
that is not achieved.

--B_3500010224_3589546
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw
MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg
TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu
bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS
4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks
HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1
IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3
kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC
4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j
BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo
AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8
MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0
cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN
BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe
f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70
ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m
4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh
nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy
EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw
NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR
Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj
eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT
QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf
auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16
CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0
dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi
BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t
L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp
AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh
AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD
AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5
ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi
AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj
gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ
KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR
XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+
W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0
UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe
knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di
bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw
MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy
dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz
c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k
Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn
eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw
OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh
z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk
VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi
Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp
GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt
eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9
8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl
bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A
nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTCW7S621KMHWDqAqcq
Nnb7AQIt1TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEx
MjgxNDAzNDNaMA0GCSqGSIb3DQEBAQUABIIBALzsJPtesFyJucdpdX/cImJBL5nKWr2Vs5BD
oAMXDTTJzExTPmKJKCj/vmgXBZJrgz36ud+aj5+HmT75C3kK6BbEbJTtgEWsj2gNjiOrD0HA
cZjcP41nsdknTPNQbNxxK7dxcivah13yqhA7VR7due+Yfym8g1P68H8UYU/Cn4Yn4EPmspwW
w+8NHhn/gEr3cpYJMjWaKRmdNXMfetdsbMYgjY/BkBFGH+mhJidi68hS1sg4mYFjf5IyJEtT
OOFNAoyrpPoKBPalhcfblRrlu/sgXIOgVFaePw9hej1km+VOM6a4etA9kyZ9L3/dFY4+XV/q
xRBdz/raewDPGkHXbKs=

--B_3500010224_3589546--


From nobody Fri Nov 28 08:40:46 2014
Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4937A1A020A for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 08:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level: 
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM4QY3EeZXbV for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 08:40:43 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587BE1A0203 for <dbound@ietf.org>; Fri, 28 Nov 2014 08:40:43 -0800 (PST)
Received: (qmail 72802 invoked from network); 28 Nov 2014 16:40:41 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 28 Nov 2014 16:40:41 -0000
Date: 28 Nov 2014 16:40:20 -0000
Message-ID: <20141128164020.28961.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/XpYIRWPqgL8-4FYF2PoJtIVVgtU
Cc: superuser@gmail.com
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 16:40:44 -0000

In article <CAL0qLwZT8MPeD4qzZeRRkcCKTK_NzxgXDbd0qD7Xu4pFZnq82w@mail.gmail.com> you write:
>On Thu, Nov 27, 2014 at 5:29 PM, Naoki Kambe <kambe@jprs.co.jp> wrote:
>
>> What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?
>
>Could be either, I imagine.

Based on experience, I thought it was Doomed BOUNDaries

>> What is the scope of this WG?  For example, is an interoperability
>> test using the solutions between a web server and a web browser
>> included in its scope?

I don't ever recall a WG having interop tests in its scope.  There are
certainly groups such as WEIRDS and DKIM that have done interop tests
as a useful side activity.

R's,
John


From nobody Fri Nov 28 08:47:24 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134681A0169 for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 08:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvQHx6LDGnN8 for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 08:47:22 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E5D1A00A2 for <dbound@ietf.org>; Fri, 28 Nov 2014 08:47:22 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sASGlG4V024850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Nov 2014 08:47:20 -0800
Message-ID: <5478A700.6070907@dcrocker.net>
Date: Fri, 28 Nov 2014 08:46:56 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John Levine <johnl@taugh.com>, dbound@ietf.org
References: <20141128164020.28961.qmail@ary.lan>
In-Reply-To: <20141128164020.28961.qmail@ary.lan>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 28 Nov 2014 08:47:20 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/rtAeM3WKFYxcisuCx5tJusszgLk
Cc: superuser@gmail.com
Subject: Re: [Dbound] Sketch charter
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 16:47:23 -0000

On 11/28/2014 8:40 AM, John Levine wrote:
>>> What is the scope of this WG?  For example, is an interoperability
>>> >> test using the solutions between a web server and a web browser
>>> >> included in its scope?
> I don't ever recall a WG having interop tests in its scope.  There are
> certainly groups such as WEIRDS and DKIM that have done interop tests
> as a useful side activity.


To expand on this a bit:

     The formal requirements for Proposed Standard do not include
demonstrating implementation or testing experience.  Very rarely, the
working group or the IESG do impose such requirements, as the working
group effort develops.  However I believe they have never been explicit
in a working group charter.

     More important than the formalities is whether work has sufficient
risk and sufficient potential benefit to motivate the community to do
interoperability testing prior to seeking Proposed.

     The upside of the testing is, of course, experience and therefore
presumed specification maturity. The downside is raising the bar for
Proposed too high.  It's a tradeoff best left to the specific working
group situation and, IMO, best left to later stages of wg process.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri Nov 28 23:54:37 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88251A00FA for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 23:54:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0OGPy9vW60S for <dbound@ietfa.amsl.com>; Fri, 28 Nov 2014 23:54:35 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478611A00DE for <dbound@ietf.org>; Fri, 28 Nov 2014 23:54:35 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ex7so12955632wid.0 for <dbound@ietf.org>; Fri, 28 Nov 2014 23:54:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zUTHtwyDWfaZ2pBUvWKSBlYQQSYzo3EvCEu1JlQ49Tc=; b=dNfav0HycHsafaFYhTDo5W/MOaCtyGrN6sOX5cMubzHFFEGqALVjfqn/M9Suo0dWB2 hQjzjXCmAwy5gfEBZtXS+/Sme7cSc9ZsIc6v88WDpqAWyrVp4XZRAXCIl1+nIDUm7DGd MTnl8QefWqsZZfC3tmemjKzdQLAlF8Pzv56Gmn6rRbEgqC+FauTRzhvk/zKHtULypJ/8 EXM52Exmp0E27s0AwkJdAQ1cDj13ALdiERx8TSC83EpNCVG/w7RAh5NcQAR+D7j+FeSP G99ZcnYGV+9eqtBSVL20vwt3ciSaKSL6sv/QMwTITBtHWNIdN6Z1XfFebhsDi/INIaof rp6Q==
MIME-Version: 1.0
X-Received: by 10.194.103.232 with SMTP id fz8mr76484519wjb.110.1417247674058;  Fri, 28 Nov 2014 23:54:34 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Fri, 28 Nov 2014 23:54:33 -0800 (PST)
In-Reply-To: <547670CF.7040504@dcrocker.net>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net> <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com> <547670CF.7040504@dcrocker.net>
Date: Fri, 28 Nov 2014 23:54:33 -0800
Message-ID: <CAL0qLwaUAGxnPYJTsLaC4u0HFgoHt-+S7H8q5z1j2AbKKFey9Q@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary=047d7bf109f02bcdc70508fab095
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/4EKcnFmw-0Y49QQzh_g5VNS49EU
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Nov 2014 07:54:37 -0000

--047d7bf109f02bcdc70508fab095
Content-Type: text/plain; charset=UTF-8

I've taken another run at addressing your concerns and Ed's, but I confess
I'm now going cross-eyed trying to understand what still needs to change.
The feedback is a little too abstract and thus I don't know what parts
still need attention and in what ways.

If you or anyone still thinks this version isn't right, please reply with
some OLD/NEW-style specific edits for me to make.  Otherwise I'm inclined
to agree with Andrew and circulate it to apps-discuss and perhaps saag and
dnsop soon.

One specific comment:

On Wed, Nov 26, 2014 at 4:31 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> My original suggestion offered a self-contained definition of org
> domain, so that no reference to dmarc would be needed.  And it defined
> it in terms that described what is functionally salient, to distinguish
> the org domain.
>

Was there specific text?  I couldn't find this suggestion upthread anywhere.

-MSK

--047d7bf109f02bcdc70508fab095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I&#39;ve taken another run at addressing your co=
ncerns and Ed&#39;s, but I confess I&#39;m now going cross-eyed trying to u=
nderstand what still needs to change.=C2=A0 The feedback is a little too ab=
stract and thus I don&#39;t know what parts still need attention and in wha=
t ways.<br><br></div>If you or anyone still thinks this version isn&#39;t r=
ight, please reply with some OLD/NEW-style specific edits for me to make.=
=C2=A0 Otherwise I&#39;m inclined to agree with Andrew and circulate it to =
apps-discuss and perhaps saag and dnsop soon.<br><br></div>One specific com=
ment:<br><div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, Nov 26, 2014 at 4:31 PM, Dave Crocker <span dir=3D"ltr">&lt;=
<a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocker.net</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My original suggestion =
offered a self-contained definition of org<br>
domain, so that no reference to dmarc would be needed.=C2=A0 And it defined=
<br>
it in terms that described what is functionally salient, to distinguish<br>
the org domain.<span class=3D""><br></span></blockquote><div><br></div><div=
>Was there specific text?=C2=A0 I couldn&#39;t find this suggestion upthrea=
d anywhere.<br><br></div>-MSK<br></div></div></div></div></div></div>

--047d7bf109f02bcdc70508fab095--


From nobody Sat Nov 29 07:29:58 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA261A1AAC for <dbound@ietfa.amsl.com>; Sat, 29 Nov 2014 07:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9AXt2QbAAwK for <dbound@ietfa.amsl.com>; Sat, 29 Nov 2014 07:29:55 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FA31A1AA5 for <dbound@ietf.org>; Sat, 29 Nov 2014 07:29:55 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sATFTnWU029936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Nov 2014 07:29:53 -0800
Message-ID: <5479E657.4010302@dcrocker.net>
Date: Sat, 29 Nov 2014 07:29:27 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net> <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com> <547670CF.7040504@dcrocker.net> <CAL0qLwaUAGxnPYJTsLaC4u0HFgoHt-+S7H8q5z1j2AbKKFey9Q@mail.gmail.com>
In-Reply-To: <CAL0qLwaUAGxnPYJTsLaC4u0HFgoHt-+S7H8q5z1j2AbKKFey9Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 29 Nov 2014 07:29:53 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/PKzy5NxdDL7yIG4t5iq3D5eFRlY
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Nov 2014 15:29:57 -0000

On 11/28/2014 11:54 PM, Murray S. Kucherawy wrote:
> I've taken another run at addressing your concerns and Ed's, but I
> confess I'm now going cross-eyed trying to understand what still needs
> to change.  The feedback is a little too abstract and thus I don't know
> what parts still need attention and in what ways.
> 
> If you or anyone still thinks this version isn't right, please reply
> with some OLD/NEW-style specific edits for me to make.  Otherwise I'm
> inclined to agree with Andrew and circulate it to apps-discuss and
> perhaps saag and dnsop soon.


See below:


> Various Internet protocols and applications require some mechanism for
> determining whether two domain names are related. A popular example is
> the need to determine whether example.com and foo.example.com, or even
> example.net, are subject to the same administrative control. To humans,
> the answer to this may be obvious. However, the Domain Name System (DNS),
> which is the service that handles domain name queries, does not currently
> provide the ability to mark these sorts of relationships. This makes it
> impossible to discern relationships algorithmically. For example, the
> right answer is not always "compare the rightmost two labels".

> The particular issue is that applications and organizations impose
> policies and procedures that create additional structure in their use of
> domain names. This creates many possible relationships that are not
> evident in the names themselves or in the operational, public
> representation of the names.

> Prior solutions for identifying relationships between domain names
> have relied primarily upon the DNS namespace and protocol to provide
> a service that actually exists outside of both. Relying on the DNS
> to do so thus renders such solutions unreliable and unnecessarily
> constrained. For example, confirming or dismissing a relationship between
> two domain names based on the existence of a zone cut or common ancestry
> is often unfounded, and the notion of an upward "tree walk" as a search
> mechanism is considered unacceptable.

Both of these examples are /within/ the protocol.  That runs contrary to
the opening assertion of this paragraph.  Other than the PSL, I've no
idea what other 'prior solutions' are being cited.  I doubt a non-expert
(or possibly expert) reader will, either.


> For the purposes of this work, domain names are approached as identifiers
> used by organizations and services, independent of underlying protocols
> or mechanisms. Specifically, the work will not propose any changes to
> DNS protocols except the possible creation of new resource record types
> (RRTYPES).

> Currently, the most well known solution in existence is the Public Suffix
> List (PSL). The PSL is maintained by a Web browser producer and is kept
> current by volunteers on a best-effort basis. It contains a list of points
> in the hierarchical namespace at which registrations take place, and is
> used to identify the boundary between so-called "public" names (below which
> registrations can occur) and the private names (i.e., organizational names)
> below them. When this list is inaccurate, it exposes a deviation from
> reality that degrades service to some and can be exploited by others. Being
> the de facto resource, and lacking a more comprehensive, alternative solution
> for relationship identification, the functionality of the PSL has often been
> misused to accomplish means beyond its capabilities. For example, there
> is no way to confirm the relationship between two domain names, only
> signal that there is or is not a public boundary between the two.
> Additionally, there are questions about the scalability, central management,
> and third-party management of the PSL as it currently exists.


The way org domain is introduced here looks interesting.  The problem is
the surrounding text.

The PSL web pages don't use the term 'private' and don't really explain
what they mean by 'public'.  Presumably they thought it obvious.  Worse,
their basic definition is pretty vague:

     A 'public suffix' is one under which Internet users can directly
register names.

In fact, given the policies for some newer registries, I suspect this
language is actually wrong.  At the least, it's not clear what "public"
and "private" mean for some of those newer TLDs.

A bit of later PSL text is more concrete and pragmatic, though still a
bit odd:

      the highest level at which a domain may be registered for a
particular top-level domain

The text that I originally offered for the charter, to explain
'organizational domain' was:

     Examples of such relationships include authority boundaries within
the hierarchy and across the hierarchy.  For the former, a 'parent'
domain name is sometimes classed as the organizational domain, to
indicate that the parent domain is at the top of a hiearchy defines a
transition from one "outside" administrative authority to another that
is "inside" the organization.


So with all that, I'll suggest adding some text above the PSL paragraph
and below the RRTYPES paragraph:

     An 'organizational domain' is a name that is at the top of an
administrative hierarchy, defining transition from one "outside"
administrative authority to another that is "inside" the organization.


> In terms of specific use cases: Within the realm of email, there is a
> desire to link an arbitrary fully-qualified domain name (FQDN) to the
> organizational domain name (at some point in the namespace above it),
> in order to identify a deterministic location where some sort of statement
> of policy regarding that FQDN can be found. With respect to the
> web, there is a similar need to identify relationships between different
> FQDNs, currently accomplished by comparing ancestries. However, there
> is also desire to reliably identify relationships outside of the realm
> and constraints of the namespace tree.

> Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
> current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
> benefit from having this capability.

> The DBOUND working group will develop one or more solutions to this family
> of problems. If possible, a unified solution will be developed. However,
> the working group may discover that the email, web, equivalence, and
> possibly other problems require independent solutions, in which case the
> working group will follow that path. The solutions may or may not involve
> changes to the DNS, such as creation of new resource record types; in any
> case, all such changes will be incremental only.

> This working group will not seek to amend the consuming protocols themselves
> (i.e., any web or mail standards) without rechartering, and only after
> completion of the base work. Any such work undertaken in parallel will
> eeed to be done as individual or independent submissions, or in another
> working group.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Sun Nov 30 21:29:15 2014
Return-Path: <superuser@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFDE1A1A10 for <dbound@ietfa.amsl.com>; Sun, 30 Nov 2014 21:29:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbQgiueK1cvP for <dbound@ietfa.amsl.com>; Sun, 30 Nov 2014 21:29:12 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D295A1A1A07 for <dbound@ietf.org>; Sun, 30 Nov 2014 21:29:11 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id a1so4858057wgh.5 for <dbound@ietf.org>; Sun, 30 Nov 2014 21:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QsfXrhjM8m4lmrYIRLVv5a1s2P2Ffvrzd9Hg0TNsNrI=; b=xBz/12R+GC537RWIWSGRgPs96wR8CkJbaTQXfAaeKxd7bNTpwtz7MhC4YDq6te9dN2 EOwEQANdiux4ZaNWPVIeZLr5KqH5UyqJWgY2QC8bsVDBvR+aMZP1akzSX2wRLAur1Mp6 +70rBsuWvt4SQ8H8k3r0A4L9tFkS5v+a6axq7JZIpYWvcbkIrjbHwBvyEXbjZfHq9qLY ThGu8Rz043gYK2P+IDoizIxmJkC3krESYI2+IAaAr2hoHACRRTn69tdOaXfpZXpbVtP7 dxl/CbbA5uWiIyj9tgMHq61U79ztpcv/P21QQkY16rSQnOL3sjGOtY/W/csgYNAfvkza noOA==
MIME-Version: 1.0
X-Received: by 10.180.91.36 with SMTP id cb4mr70887014wib.30.1417411750631; Sun, 30 Nov 2014 21:29:10 -0800 (PST)
Received: by 10.27.76.134 with HTTP; Sun, 30 Nov 2014 21:29:10 -0800 (PST)
In-Reply-To: <5479E657.4010302@dcrocker.net>
References: <F70D6D82-662B-40A0-917A-45E2C60B1D72@gmail.com> <20141126004709.26151.qmail@ary.lan> <CAL0qLwYVbW2VcK6yUggEiRRrME-YMQ8gr0VX3PN_MXtqh0Es7A@mail.gmail.com> <5475FF08.9040809@dcrocker.net> <CAL0qLwb1M6B=St8EaEc0z0KP6weynX26JODasZWrmwf2i8ansQ@mail.gmail.com> <547670CF.7040504@dcrocker.net> <CAL0qLwaUAGxnPYJTsLaC4u0HFgoHt-+S7H8q5z1j2AbKKFey9Q@mail.gmail.com> <5479E657.4010302@dcrocker.net>
Date: Sun, 30 Nov 2014 21:29:10 -0800
Message-ID: <CAL0qLwZOD_y=-9_WcZgkR+SrzhJAksrk-cgUzUpMwfD7nQSj=A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary=f46d043d6711e59ffa050920e3ef
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/UnfVIjOHvzhFUgGf9275SXpnY7o
Cc: "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 05:29:13 -0000

--f46d043d6711e59ffa050920e3ef
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 29, 2014 at 7:29 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> > Prior solutions for identifying relationships between domain names
> > have relied primarily upon the DNS namespace and protocol to provide
> > a service that actually exists outside of both. Relying on the DNS
> > to do so thus renders such solutions unreliable and unnecessarily
> > constrained. For example, confirming or dismissing a relationship between
> > two domain names based on the existence of a zone cut or common ancestry
> > is often unfounded, and the notion of an upward "tree walk" as a search
> > mechanism is considered unacceptable.
>
> Both of these examples are /within/ the protocol.  That runs contrary to
> the opening assertion of this paragraph.  Other than the PSL, I've no
> idea what other 'prior solutions' are being cited.  I doubt a non-expert
> (or possibly expert) reader will, either.
>

Both of those are examples of something happening via the protocol to try
to discover something that exists completely outside of the protocol, and
it doesn't work.  That's what the cited paragraph is trying to say.

So with all that, I'll suggest adding some text above the PSL paragraph
> and below the RRTYPES paragraph:
>
>      An 'organizational domain' is a name that is at the top of an
> administrative hierarchy, defining transition from one "outside"
> administrative authority to another that is "inside" the organization.
>

Added.

-MSK

--f46d043d6711e59ffa050920e3ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Nov 29, 2014 at 7:29 AM, Dave Crocker <span dir=3D=
"ltr">&lt;<a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocke=
r.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D""></span>&gt; Prior=
 solutions for identifying relationships between domain names<br>
&gt; have relied primarily upon the DNS namespace and protocol to provide<b=
r>
&gt; a service that actually exists outside of both. Relying on the DNS<br>
&gt; to do so thus renders such solutions unreliable and unnecessarily<br>
<span class=3D"">&gt; constrained. For example, confirming or dismissing a =
relationship between<br>
&gt; two domain names based on the existence of a zone cut or common ancest=
ry<br>
</span>&gt; is often unfounded, and the notion of an upward &quot;tree walk=
&quot; as a search<br>
&gt; mechanism is considered unacceptable.<br>
<br>
Both of these examples are /within/ the protocol.=C2=A0 That runs contrary =
to<br>
the opening assertion of this paragraph.=C2=A0 Other than the PSL, I&#39;ve=
 no<br>
idea what other &#39;prior solutions&#39; are being cited.=C2=A0 I doubt a =
non-expert<br>
(or possibly expert) reader will, either.<br></blockquote><div><br></div><d=
iv>Both of those are examples of something happening via the protocol to tr=
y to discover something that exists completely outside of the protocol, and=
 it doesn&#39;t work.=C2=A0 That&#39;s what the cited paragraph is trying t=
o say.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So with all that, I&#39;ll suggest adding some text above the PSL paragraph=
<br>
and below the RRTYPES paragraph:<br>
<br>
=C2=A0 =C2=A0 =C2=A0An &#39;organizational domain&#39; is a name that is at=
 the top of an<br>
administrative hierarchy, defining transition from one &quot;outside&quot;<=
br>
administrative authority to another that is &quot;inside&quot; the organiza=
tion.<br></blockquote><div><br></div><div>Added.<br><br></div><div>-MSK<br>=
</div></div></div></div>

--f46d043d6711e59ffa050920e3ef--