From nobody Wed Mar 4 14:00:05 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66D1A8980; Wed, 4 Mar 2015 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 wxurZhZCp_3Y; Wed, 4 Mar 2015 14:00: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 3F1E11A8978; Wed, 4 Mar 2015 14:00:01 -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 BE8658A035; Wed, 4 Mar 2015 21:59:59 +0000 (UTC) Date: Wed, 4 Mar 2015 16:59:58 -0500 From: Andrew Sullivan To: Barry Leiba Message-ID: <20150304215958.GD1197@mx1.yitter.info> References: <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Richard Barnes , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 22:00:03 -0000 Hi, Murray made an update. It's at https://github.com/mskucherawy/docs/blob/master/charter-dbound. Richard, is it ok? (Murray sent this some while ago, but maybe you were looking for a ping from me.) A On Mon, Feb 02, 2015 at 02:33:52PM -0500, Barry Leiba wrote: > >>> I think it would be sufficient to just say, that "related" is not a > >>> unitary concept, and that there will be different flavors of > >>> relationship. > >> > >> Excellent. I think this was exactly the difference we were having > >> before, and I'm glad we now agree that it's part of the work for the > >> WG, not pre-WG. Thanks! > > > > Great. I do think some text refactoring is necessary here, though. Let me > > know when you've got a proposal. > > It's been almost a week since this exchange... Any text coming? > Andrew, are you the one on the hook for proposing text? > > Barry > > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 6 09:46:17 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F951A0065 for ; Fri, 6 Mar 2015 09:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J33oLM39XNps for ; Fri, 6 Mar 2015 09:46:13 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD181A0222 for ; Fri, 6 Mar 2015 09:46:11 -0800 (PST) Received: by lbiz12 with SMTP id z12so36313214lbi.5 for ; Fri, 06 Mar 2015 09:46:09 -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=sx3eJ84PuIFTcAyBTmAKM9uV7jZr16OBsallqupkFm4=; b=lAoajC3ej/48bWxb5Kk+jguUEl46+VR7wKCuqCUZzjx+N+MRxUm+qnPw4O/+l1oULB ZW5bW1rGvwE7ydrksj/AEva/Eqfmcc+WVGvDh8rXwUT4U0LKYP4XEc5F6QZ9ICUNjeRX 2Ue8NG7C5bpTSfMK0zVASdYFtd+E+PcjxmW/ThAFUonSO4nMEESeCoaXaoqdX6snhbMA OD7fOLhge+A8P5SMsqGNn9Zv+vOcpwpVNRN8GIOLVjTvx4pOqBEMOrzXuSMow4fIVhQd zk+zVZbLwGwPvQymCd7GhdGlB+pYNoBjgO2P/MKxzDi5o/gUNIiaqGIu7y3HaEb6eBcw nTJg== X-Gm-Message-State: ALoCoQlYc+y13fAg3+6YcmQnAdsvoOpIGZc7ZSylIttUpmW3ClxYZLLFXNop+9YIPVxWhDNcFFWV MIME-Version: 1.0 X-Received: by 10.152.179.139 with SMTP id dg11mr8219472lac.28.1425663969536; Fri, 06 Mar 2015 09:46:09 -0800 (PST) Received: by 10.25.135.4 with HTTP; Fri, 6 Mar 2015 09:46:09 -0800 (PST) In-Reply-To: <20150304215958.GD1197@mx1.yitter.info> References: <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> <20150304215958.GD1197@mx1.yitter.info> Date: Fri, 6 Mar 2015 12:46:09 -0500 Message-ID: From: Richard Barnes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a113491927942100510a24262 Archived-At: Cc: Barry Leiba , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:46:14 -0000 --001a113491927942100510a24262 Content-Type: text/plain; charset=UTF-8 Thanks for the ping. I cleared. On Wed, Mar 4, 2015 at 4:59 PM, Andrew Sullivan wrote: > Hi, > > Murray made an update. It's at > https://github.com/mskucherawy/docs/blob/master/charter-dbound. > Richard, is it ok? (Murray sent this some while ago, but maybe you > were looking for a ping from me.) > > A > > On Mon, Feb 02, 2015 at 02:33:52PM -0500, Barry Leiba wrote: > > >>> I think it would be sufficient to just say, that "related" is not a > > >>> unitary concept, and that there will be different flavors of > > >>> relationship. > > >> > > >> Excellent. I think this was exactly the difference we were having > > >> before, and I'm glad we now agree that it's part of the work for the > > >> WG, not pre-WG. Thanks! > > > > > > Great. I do think some text refactoring is necessary here, though. > Let me > > > know when you've got a proposal. > > > > It's been almost a week since this exchange... Any text coming? > > Andrew, are you the one on the hook for proposing text? > > > > Barry > > > > _______________________________________________ > > Dbound mailing list > > Dbound@ietf.org > > https://www.ietf.org/mailman/listinfo/dbound > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > --001a113491927942100510a24262 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the ping.=C2=A0 I cleared.

On Wed, Mar 4, 2015 at 4:59 PM, An= drew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

Murray made an update.=C2=A0 It's at
https://github.com/mskucherawy/docs/blob/master/charter-d= bound.
Richard, is it ok?=C2=A0 (Murray sent this some while ago, but maybe you were looking for a ping from me.)

A

On Mon, Feb 02, 2015 at 02:33:52PM -0500, Barry Leiba wrote:
> >>> I think it= would be sufficient to just say, that "related" is not a
> >>> unitary concept, and that there will be different flavors= of
> >>> relationship.
> >>
> >> Excellent.=C2=A0 I think this was exactly the difference we w= ere having
> >> before, and I'm glad we now agree that it's part of t= he work for the
> >> WG, not pre-WG.=C2=A0 Thanks!
> >
> > Great.=C2=A0 I do think some text refactoring is necessary here, = though.=C2=A0 Let me
> > know when you've got a proposal.
>
> It's been almost a week since this exchange... Any text coming? > Andrew, are you the one on the hook for proposing text?
>
> Barry
>
> __________________= _____________________________
> Dbound mailing list
> Dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound

--
Andrew Sullivan
ajs@anvilwalrusden.com

--001a113491927942100510a24262-- From nobody Fri Mar 6 10:51:31 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB9B1A1BC6; Fri, 6 Mar 2015 10:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uVRPz3Z3hMJ; Fri, 6 Mar 2015 10:51:26 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE791A1BB8; Fri, 6 Mar 2015 10:51:25 -0800 (PST) Received: by lbiz12 with SMTP id z12so31626032lbi.12; Fri, 06 Mar 2015 10:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jqwP75DYuRVtwagGyqcR3ZULcKJPtZBb14rCPrY58xk=; b=tG1lLSKDrVdVkPb2deZd1TUjUYQ/hPwEpUKGdhoDbqjV/xg9YIQCuB9nrkuBpRmL0d 5BAyLkbJPE8nqdwahbWf5ZPicq5hzLK9PPkr91UYwtF9HUHO0fXbtuT3BZlDRuSdIPJd U+BsZF9si+UzoPH58bkjRVCWeTKR00GgZm+IsYiz/z3yI+mLDW3U601srL2RjBZl0MI+ 9yl9XPnPogI1Qcw56NRsERWqh5SORvtKXTCjk28v2qjHSwOkHKA2d9zUuNRiQfSMdm11 OhoaGlRsKjXi5k7rCv+YDjW+91Ji4FFAN2OCkwKt0pwBbkm0J2+OSqrLWL+S/U/kSB6P Utzw== MIME-Version: 1.0 X-Received: by 10.112.133.225 with SMTP id pf1mr14352240lbb.33.1425667884458; Fri, 06 Mar 2015 10:51:24 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Fri, 6 Mar 2015 10:51:24 -0800 (PST) In-Reply-To: References: <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> <20150304215958.GD1197@mx1.yitter.info> Date: Fri, 6 Mar 2015 19:51:24 +0100 X-Google-Sender-Auth: tfJanbsVBJv56dSAb4Plr7p1Ypk Message-ID: From: Barry Leiba To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Eliot Lear , The IESG , Andrew Sullivan , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:51:27 -0000 > Thanks for the ping. I cleared. Thanks, Richard. And I have updated the charter in the datatracker, and asked the Secretariat to initiate External Review. Barry > On Wed, Mar 4, 2015 at 4:59 PM, Andrew Sullivan > wrote: >> >> Hi, >> >> Murray made an update. It's at >> https://github.com/mskucherawy/docs/blob/master/charter-dbound. >> Richard, is it ok? (Murray sent this some while ago, but maybe you >> were looking for a ping from me.) >> >> A >> >> On Mon, Feb 02, 2015 at 02:33:52PM -0500, Barry Leiba wrote: >> > >>> I think it would be sufficient to just say, that "related" is not a >> > >>> unitary concept, and that there will be different flavors of >> > >>> relationship. >> > >> >> > >> Excellent. I think this was exactly the difference we were having >> > >> before, and I'm glad we now agree that it's part of the work for the >> > >> WG, not pre-WG. Thanks! >> > > >> > > Great. I do think some text refactoring is necessary here, though. >> > > Let me >> > > know when you've got a proposal. >> > >> > It's been almost a week since this exchange... Any text coming? >> > Andrew, are you the one on the hook for proposing text? >> > >> > Barry >> > >> > _______________________________________________ >> > Dbound mailing list >> > Dbound@ietf.org >> > https://www.ietf.org/mailman/listinfo/dbound >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com > > From nobody Fri Mar 6 11:22:53 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527B1A3BA7; Fri, 6 Mar 2015 11:22:49 -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 4M4Ju_3K1nhd; Fri, 6 Mar 2015 11:22:47 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97CD1A6F01; Fri, 6 Mar 2015 11:22:32 -0800 (PST) Received: by wiwl15 with SMTP id l15so5954471wiw.0; Fri, 06 Mar 2015 11:22: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=peYIpA0Wy4mGN4WzwO2rrefJip92N8OiB5BSyVBV/Z0=; b=MY/oSzkHNnmQBwQj99c7u3VCyPx8VTVW+Cz9yZYrRxMM9Acm4cZlrm9Rgi17hH027/ nt7OQ7qboEI5NiDub/r+jwqHoFGE0HqbAow7muDfRfCJ4DF9PVNKhK9dsoB9+nUIXRAH 8dphDmy8qzXos5FxM70cX/IY7uf+j7sUxq/5R+Dnm1IP54Tew3O09rh7528VDGmicdM2 JKxNeHyCcNNh1SXySrYbToq5sAyAeAk25Rtsyg5EFLhUcYQqkc3ugu9munud0eiiw0j0 fvna94AtmIdCrqPHiwYwMXo6j9W5J+atN76bA2jvKtiY8c2HS93V5LE3CaSjSjwxwo+7 DA0A== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr31601072wjc.111.1425669751646; Fri, 06 Mar 2015 11:22:31 -0800 (PST) Received: by 10.27.179.212 with HTTP; Fri, 6 Mar 2015 11:22:31 -0800 (PST) In-Reply-To: <20150122153701.32070.13832.idtracker@ietfa.amsl.com> References: <20150122153701.32070.13832.idtracker@ietfa.amsl.com> Date: Fri, 6 Mar 2015 11:22:31 -0800 Message-ID: From: "Murray S. Kucherawy" To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7bacb11e1d2fc30510a39b32 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Benoit Claise's Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:22:49 -0000 --047d7bacb11e1d2fc30510a39b32 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 22, 2015 at 7:37 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-dbound-00-01: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-dbound/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > A related problem is known as the "equivalence problem", which is a > desire to express that two domains are equivalent, without using > existing facilities like CNAME or DNAME that necessitate one of the > names being authoritative over the other. > > "A related problem". Does it mean that the WG is chartered to solve this > issue as well? I'm not sure. > The following sentence doesn't help me: > The DBOUND working group will develop a unified solution, if possible, > for determining organizational domain boundaries. > Hi Benoit, The proposed charter revision removes the text you find to be a problem. The new text is here: https://github.com/mskucherawy/docs/blob/master/charter-dbound Does this resolve your concern? -MSK --047d7bacb11e1d2fc30510a39b32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 22, 2015 at 7:37 AM, Benoit Claise <bclaise= @cisco.com> wrote:
Benoit C= laise has entered the following ballot position for
charter-ietf-dbound-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-dbound/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

A related problem is known as the "equivalence problem", which is= a
desire to express that two domains are equivalent, without using
existing facilities like CNAME or DNAME that necessitate one of the
names being authoritative over the other.

"A related problem". Does it mean that the WG is chartered to sol= ve this
issue as well? I'm not sure.
The following sentence doesn't help me:
The DBOUND working group will develop a unified solution, if possible,
for determining organizational domain boundaries.

=
Hi Benoit,

The proposed charter revision remov= es the text you find to be a problem.=C2=A0 The new text is here:

ht= tps://github.com/mskucherawy/docs/blob/master/charter-dbound

Does this resolve your concern?

-MSK
--047d7bacb11e1d2fc30510a39b32-- From nobody Fri Mar 6 11:57:56 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D351A7005; Fri, 6 Mar 2015 11:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kPqhdxBG7Lv; Fri, 6 Mar 2015 11:57:46 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1371A7003; Fri, 6 Mar 2015 11:57:40 -0800 (PST) Received: by labgf13 with SMTP id gf13so35259415lab.5; Fri, 06 Mar 2015 11:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pJ2GwnHDuBUqcjMMbbFwt7Jfjnie6sgcbKkvCy5yzx4=; b=b5KeuMLSsy0fZF3Wu3+ewfnXbfJ9cAD8KjFQ2qArvL3WJmPFDrV4ioiM5R+thbVnRb 8JJe9fS592EsbKKfhoCAed7owS8M/yKuu17zZHnpW8YkLq2Ta/nE5qHcIy+rL/jb661O ddPFZYdgWoTJKyEhoN8Es6bbP0ZxgMAmfm/2Jm1BY00xpw0qI8TlL1wYHzvq/ROK+HKk clnD4PC9Iql24iiJQFZ8c4lj6DaiH1mWnGuKvxCZQWL8Y/WA0kRJaXu0dOX+rbpsLesS 81NELHmLIIBrTKtxDGeR1Z6K3/dXcwhZWA5m2PNvB8Vr89J5nOaebxnpv3FOP4SwoqS5 a+NA== MIME-Version: 1.0 X-Received: by 10.152.243.4 with SMTP id wu4mr14580823lac.33.1425671859100; Fri, 06 Mar 2015 11:57:39 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Fri, 6 Mar 2015 11:57:39 -0800 (PST) In-Reply-To: References: <20150122153701.32070.13832.idtracker@ietfa.amsl.com> Date: Fri, 6 Mar 2015 20:57:39 +0100 X-Google-Sender-Auth: JXSX2AThbrCK3BCRrarlEzhTk7w Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Benoit Claise , The IESG , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Benoit Claise's Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:57:47 -0000 The new text is in the datatracker, in the usual charter place: https://datatracker.ietf.org/doc/charter-ietf-dbound/ Barry On Fri, Mar 6, 2015 at 8:22 PM, Murray S. Kucherawy wrote: > On Thu, Jan 22, 2015 at 7:37 AM, Benoit Claise wrote: >> >> Benoit Claise has entered the following ballot position for >> charter-ietf-dbound-00-01: Block >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/charter-ietf-dbound/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> A related problem is known as the "equivalence problem", which is a >> desire to express that two domains are equivalent, without using >> existing facilities like CNAME or DNAME that necessitate one of the >> names being authoritative over the other. >> >> "A related problem". Does it mean that the WG is chartered to solve this >> issue as well? I'm not sure. >> The following sentence doesn't help me: >> The DBOUND working group will develop a unified solution, if possible, >> for determining organizational domain boundaries. > > > Hi Benoit, > > The proposed charter revision removes the text you find to be a problem. > The new text is here: > > https://github.com/mskucherawy/docs/blob/master/charter-dbound > > Does this resolve your concern? > > -MSK From nobody Fri Mar 6 15:37:19 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB091A870D; Fri, 6 Mar 2015 15:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6G--lRyK781; Fri, 6 Mar 2015 15:37:16 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224331A1C06; Fri, 6 Mar 2015 15:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5901; q=dns/txt; s=iport; t=1425685036; x=1426894636; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=dAWWaPAH0FRzzmlMeiabWuUjRKVWm+rqOl7Bq946KaM=; b=IAvq3y5zR844FNYRrxNrXu1iTv4yV1INy9Xx/l25WcIU+6cXymIk3q2D FM3fZ/dkf7Q5tkoPfP7XXQidzTPREWNQPwIgL9DiNNVFT8+GVrXVq9/lK L5HXHTdjVKL1Pq2ejJkdLoBz0qXVXON70/fTpYJEe8fgsRWUcwL2wawM4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DGBADLOPpU/xbLJq1cg1iDZLURg0+EMYFHhXACgWoUAQEBAQEBAXyEEAEBBCNVARALGAkWCAMCAgkDAgECATQRBg0BBQIBAReIFA2zWJkUAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sShAwRAVAHgmiBQwWFbo1nhWaBGjmCZoIxiS2DPiODbz0xgQuBOAEBAQ X-IronPort-AV: E=Sophos;i="5.11,355,1422921600"; d="scan'208,217";a="368149110" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 06 Mar 2015 23:37:14 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t26NbDYJ001399; Fri, 6 Mar 2015 23:37:13 GMT Message-ID: <54FA3A23.4030601@cisco.com> Date: Sat, 07 Mar 2015 00:37:07 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20150122153701.32070.13832.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070709060801040205000803" Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Benoit Claise's Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:37:18 -0000 This is a multi-part message in MIME format. --------------070709060801040205000803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/03/2015 20:22, Murray S. Kucherawy wrote: > On Thu, Jan 22, 2015 at 7:37 AM, Benoit Claise > wrote: > > Benoit Claise has entered the following ballot position for > charter-ietf-dbound-00-01: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-dbound/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > A related problem is known as the "equivalence problem", which is a > desire to express that two domains are equivalent, without using > existing facilities like CNAME or DNAME that necessitate one of the > names being authoritative over the other. > > "A related problem". Does it mean that the WG is chartered to > solve this > issue as well? I'm not sure. > The following sentence doesn't help me: > The DBOUND working group will develop a unified solution, if possible, > for determining organizational domain boundaries. > > > Hi Benoit, > > The proposed charter revision removes the text you find to be a > problem. The new text is here: > > https://github.com/mskucherawy/docs/blob/master/charter-dbound > > Does this resolve your concern? Yes, thanks. Just cleared. Regards, Benoit > > -MSK --------------070709060801040205000803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 06/03/2015 20:22, Murray S. Kucherawy wrote:
On Thu, Jan 22, 2015 at 7:37 AM, Benoit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for
charter-ietf-dbound-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-dbound/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

A related problem is known as the "equivalence problem", which is a
desire to express that two domains are equivalent, without using
existing facilities like CNAME or DNAME that necessitate one of the
names being authoritative over the other.

"A related problem". Does it mean that the WG is chartered to solve this
issue as well? I'm not sure.
The following sentence doesn't help me:
The DBOUND working group will develop a unified solution, if possible,
for determining organizational domain boundaries.

Hi Benoit,

The proposed charter revision removes the text you find to be a problem.  The new text is here:

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

Does this resolve your concern?
Yes, thanks.
Just cleared.

Regards, Benoit

-MSK

--------------070709060801040205000803-- From nobody Fri Mar 6 16:41:55 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1D1A8790 for ; Fri, 6 Mar 2015 16:41:54 -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 uqhDnxnXSLaQ for ; Fri, 6 Mar 2015 16:41:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 585481A8798 for ; Fri, 6 Mar 2015 16:41:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307004135.21207.92042.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:41:35 -0800 From: IETF Secretariat Archived-At: Subject: [dbound] State changed: charter-ietf-dbound-00-02 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:41:54 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-dbound/ From nobody Fri Mar 6 16:42:02 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5590D1A877A; Fri, 6 Mar 2015 16:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MceF5neTiN9; Fri, 6 Mar 2015 16:42:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AE41A8784; Fri, 6 Mar 2015 16:41:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307004142.30299.29190.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:41:42 -0800 From: IETF Secretariat Archived-At: Subject: [dbound] Telechat update notice: X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:42:01 -0000 Telechat date has been changed to 2015-04-09 from 2015-01-22 ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-dbound/ From nobody Sat Mar 7 00:22:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B75A1A876A; Fri, 6 Mar 2015 16:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 CW65lNjnrIPr; Fri, 6 Mar 2015 16:41:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 123071A700F; Fri, 6 Mar 2015 16:41:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307004109.29910.50676.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:41:09 -0800 Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2015 00:22:32 -0800 Cc: Internet Directorate , dbound WG Subject: [dbound] WG Review: Domain Boundaries (dbound) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:41:11 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-16. Domain Boundaries (dbound) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: dbound@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitart concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful 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 provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". 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 sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section, below, for more details. For the purpose of this work, domain names are identifiers used by organizations and services, independent of underlying protocols or mechanisms. We define an "organizational domain" to be 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. The current way most of this is handled is via a list published at publicsuffix.org, and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) without rechartering, and such rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: - TBD Additional Background Information --------------------------------- [to be moved to a Wiki on chartering] The concept of an administrative boundary is by definition not present in the DNS. Relying on the DNS to divine administrative structure 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, therefore, unacceptable. 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, such as ".com" or ".org.uk") and the private names (organizational names) that domain registrars create within them. When this list is inaccurate, it exposes a deviation from reality that degrades service to some and can be exploited by others. As the PSL is the de-facto resource, and as there is not a more comprehensive, alternative solution for relationship identification, the PSL has often been misused to accomplish things beyond its capabilities. For example, there is no way to confirm the relationship between two domain names -- the PSL may 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 (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. Work such as DMARC (draft-kucherawy-dmarc-base), will certainly benefit from having this capability. From nobody Tue Mar 10 08:13:09 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169891A0027 for ; Tue, 10 Mar 2015 08:13:08 -0700 (PDT) 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 2fGMyWzkayjv for ; Tue, 10 Mar 2015 08:13:06 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C827A1A0016 for ; Tue, 10 Mar 2015 08:12:59 -0700 (PDT) Received: by igbhn18 with SMTP id hn18so3836246igb.2 for ; Tue, 10 Mar 2015 08:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=8IB/SJZ8ZoSF0lZWe41HUiSUdKmy6raeYnb5V9rHT/I=; b=Wy9onDEAgCkmZbLRef71GZe8W+t0EK2wOsN33DNIq4hbVMp7786jzFuGY6bs5Qwx86 wbB+cRZ9UMKQEUF7cBTgcxFiazDcoSSrfMQmVk62H9puwsq7wSJIJ+vp7shf1a0vC3i6 Q3rKtKdn3lzEbcl3mtIO8OobpjKZPZ897UBCA= 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=8IB/SJZ8ZoSF0lZWe41HUiSUdKmy6raeYnb5V9rHT/I=; b=U5qmo6gbm/+b4rmSGJHS6pwrmhPj5OzIyvII2+nYctPiwfTtaFhhwlnkZDqDjtfYD+ Y3N3Qg2nTgNm+kuCub5sZoYBj2Bkgq7XeaVyEKEGGOG0opcCqCG/sJ9QxFairCRImo0t wIUO/M7S+T9Lh8XXub9wiiBn+qQGuhEfpZa0vLs+B5mX/gHQucEFODTfy7HM+NB1MNa/ Tzw13XFIzQlreTy/GXmB+o1d9OksNvxHPWaRbl4Kv9IdTdQwAM9k2It9qnstdwMRdlE/ eKSvISR0AlL8qKtDKfMqmTw/xHpU+xBZmbkEwrzV65r05UHzH6G70i6PFh+9pVjlTqRo omXA== X-Gm-Message-State: ALoCoQkeYVG6e5/t7URZTIOJpC8YWJbPQnXQ3yhd93psHHhHKX4V+5fJDY3t8GmMmfp7O+lQtL8q MIME-Version: 1.0 X-Received: by 10.42.110.73 with SMTP id o9mr34403697icp.7.1426000379215; Tue, 10 Mar 2015 08:12:59 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Tue, 10 Mar 2015 08:12:59 -0700 (PDT) Date: Tue, 10 Mar 2015 11:12:59 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=485b397dd0550db7440510f09625 Archived-At: Subject: [dbound] Domain Name Relationships - I-D X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:13:08 -0000 --485b397dd0550db7440510f09625 Content-Type: text/plain; charset=UTF-8 The problem statement document that I posted to the DBOUND mailing list back in November has been revised as a more general document on Domain Name Relationships and considerations for solutions to identify them. An I-D based on the revision has been created. Information below. Regards, Casey -------- Name: draft-deccio-domain-name-relationships Revision: 00 Title: Concepts for Domain Name Relationships Document date: 2015-03-09 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-deccio-domain-name-relationships-00.txt Status: https://datatracker.ietf.org/doc/draft-deccio-domain-name-relationships/ Htmlized: http://tools.ietf.org/html/draft-deccio-domain-name-relationships-00 Abstract: Various Internet protocols and applications require some mechanism for identifying relationships between Domain Name System (DNS) names. In this document we provide examples of protocols and applications for which knowledge of these relationships is useful, if not required. Further we discuss the various types of domain name relationships, review current needs and solutions, and identify considerations for solution sets. --485b397dd0550db7440510f09625 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem statement document that I posted to the D= BOUND mailing list back in November has been revised as a more general docu= ment on Domain Name Relationships and considerations for solutions to ident= ify them.=C2=A0 An I-D based on the revision has been created.=C2=A0 Inform= ation below.

Regards,
Casey

--= ------

Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 draft-de= ccio-domain-name-relationships
Revision:=C2=A0=C2=A0=C2=A0 00
Title:= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Concepts for Domain Name Relationship= s
Document date:=C2=A0=C2=A0=C2=A0 2015-03-09
Group:=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 12
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-draft= s/draft-deccio-domain-name-relationships-00.txt
Status:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org= /doc/draft-deccio-domain-name-relationships/
Htmlized:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-deccio-doma= in-name-relationships-00


Abstract:
=C2=A0 Various Interne= t protocols and applications require some mechanism
=C2=A0 for identifyi= ng relationships between Domain Name System (DNS) names.
=C2=A0 In this = document we provide examples of protocols and applications
=C2=A0 for wh= ich knowledge of these relationships is useful, if not
=C2=A0 required.= =C2=A0 Further we discuss the various types of domain name
=C2=A0 relati= onships, review current needs and solutions, and identify
=C2=A0 conside= rations for solution sets.
--485b397dd0550db7440510f09625-- From nobody Thu Mar 12 07:03:50 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBD21A01D5 for ; Thu, 12 Mar 2015 07:03:49 -0700 (PDT) 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 AzjUYRqfi-NZ for ; Thu, 12 Mar 2015 07:03:48 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F841A01EA for ; Thu, 12 Mar 2015 07:03:48 -0700 (PDT) Received: by iegc3 with SMTP id c3so42329134ieg.3 for ; Thu, 12 Mar 2015 07:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=yGYX9q1V5Sv+usXI8+YGPSd0pHr6s0lyRA0bS/K5wJc=; b=ZIgYWTO8CupCYm6E7bxo8haAbB8ex2kaHNvudr/qL+sUc22CCnAUGpKCOurCr2ZTfB gnTQdkEKJhAikn5REE31F7QOQd4s4mEPXSzYiQzDz5iLcbK0GITNRPN3IpeAG9ZDWpyT OkFn5g2+r0E0oYIn4ZcRmCtAlUkxVa+aafAeM= 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=yGYX9q1V5Sv+usXI8+YGPSd0pHr6s0lyRA0bS/K5wJc=; b=dD2hMF62MRUp7iG//Fxn2yDUVuYjhqoZW2Uo50d42UGMjOE8/cF1LdYSTYh8m2mx7w newL0LBfkq13BQlQWXghuUjMSYJq61/RKpzYkoJbdM+3A/U8T4CZi99wiZ5Ub6ypD1b9 eFOfNXsTvAFxZ+62oumzSBAdB0mab0Vez55o5ZxOUyYJJPb49XI83K1vD0z/o6NyinhR ekP5wILMKRvbVVEbPID31VUz2eSVkNe3Dv8+dq06de/qF3XfetUMgpeIAS5hAvBy50Qv VImCMt0L9NHufJBGHdL1gdX5UVyBalsUPvgKUsI0pEvuj/nQ0QT15KU6GUWzTGxVhW9T 1exQ== X-Gm-Message-State: ALoCoQmLK8Pv/akO6aOA3+G/x/gXOLYPpy73XjWk7bx0PtKvjmbexqSDbUaXAYclNP8RuaKkvSg6 MIME-Version: 1.0 X-Received: by 10.50.39.112 with SMTP id o16mr74090918igk.0.1426169027348; Thu, 12 Mar 2015 07:03:47 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Thu, 12 Mar 2015 07:03:47 -0700 (PDT) Date: Thu, 12 Mar 2015 10:03:47 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdca2f443f0b1051117da8b Archived-At: Subject: [dbound] DBOUND plans X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:03:49 -0000 --047d7bdca2f443f0b1051117da8b Content-Type: text/plain; charset=UTF-8 According to the datatracker the DBOUND WG charter is in external review and is on the agenda for the Apr 9 telechat. What does this mean as far as plans for this IETF, in official or unofficial capacity? Regards, Casey --047d7bdca2f443f0b1051117da8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
According to the datatracker the DBOUND WG chart= er is in external review and is on the agenda for the Apr 9 telechat.=C2=A0= What does this mean as far as plans for this IETF, in official or unoffici= al capacity?

Regards,
Casey
--047d7bdca2f443f0b1051117da8b-- From nobody Mon Mar 23 09:53:38 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0825D1ACDAC for ; Mon, 23 Mar 2015 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.067 X-Spam-Level: X-Spam-Status: No, score=-101.067 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, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvfE7jVAkyfV for ; Mon, 23 Mar 2015 09:53:31 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 237AC1ACDA4 for ; Mon, 23 Mar 2015 09:53:31 -0700 (PDT) Received: (qmail 29722 invoked by uid 0); 23 Mar 2015 16:53:30 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 23 Mar 2015 16:53:30 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id 74tP1q01B2UhLwi014tS2p; Mon, 23 Mar 2015 10:53:28 -0600 X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=XuYyiiJQKFMA:10 a=a3RUe-snR5AA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=G3-J1MMgUXwA:10 a=emO1SXQWCLwA:10 a=W0ucIhDPAAAA:8 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=kewnc1ipAAAA:8 a=7u2kzkQ9AAAA:8 a=m9shYIPOAAAA:8 a=zCHD0xgTAAAA:8 a=QLhupLqRAAAA:8 a=HHdnZQ_pAAAA:8 a=HD5AUDN3POcr3To-pqMA:9 a=-KlALxvtb9Wjgxm_:21 a=AdAFITw9fNqKYgpx:21 a=QEXdDO2ut3YA:10 a=X2uToKMYv6UA:10 a=XG35I0THNlUA:10 a=daTZs8vOTEwA:10 a=cXyX8iA6zZMA:10 a=4rq7TwIXcRUA: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=PBojxjvO5u5sPVQedPKs1mqV2+V/gfT9wKwtIeIeHyQ=; b=25UD8rKq7JUoZhLICqqu051csx/KLSGVB+7OeQ4u3SecWITUNcU8QGITZ29GsBCyx7zKnDLNj0wBQjPFLpEeFe0x594yGzhI/NWca231dDFi+p0EFZN20LGHG+PO6ASw; Received: from [31.133.128.60] (port=58518) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ya5bR-0001uF-Ob for dbound@ietf.org; Mon, 23 Mar 2015 10:53:25 -0600 Message-ID: <55104501.3070906@KingsMountain.com> Date: Mon, 23 Mar 2015 09:53:21 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dbound@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.128.60 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:53:36 -0000 overall, I am curious about the focus on "public" vs "private" in draft-deccio-domain-name-relationships-00, and how the latter doc might relate to draft-sullivan-dbound-problem-statement-00 [0] ? it seems to me that, as described in [0], the deployed actuality is that there is a multitude of policy variations between domain name registries.. A particularly important distinction for security purposes is the one between names that are mostly used to contain other domains, as compared to those that are mostly used to operate services. The former are often "delegation-centric" domains, delegating parts of their name space to others, and are frequently called "public suffix" domains or "effective TLDs". The term "public suffix" comes from a site, [publicsuffix.org], that publishes a list of domains -- which is also known as the "effective TLD (eTLD) list", and henceforth in this specification as the "public suffix list" -- that are used to contain other domains. Not all, but most, delegation-centric domains are public suffix domains; and not all public suffix domains need to do DNS delegation, although most of them do. The reason for the public suffix list is to make the distinction between names that must never be treated as being in the same policy realm as another, and those that might be so treated. For instance, if "com" is on the public suffix list, that means that "example.com" lies in a policy realm distinct from that of com. ..and that the above description succinctly captures such nuances, as well as defining the more generic term "policy realm", and that the coarse distinction of "public" vs "private" doesn't sufficently reflect the overall nuances of deployed reality. my stream-of-consciousness-while-on-a-plane comments on draft-deccio-domain-name-relationships-00 are below, fyi/fwiw, but the above is my overall takeaway. i hope this is helpful, =JeffH [0] http://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-00 [1] http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01 > Internet Engineering Task Force C. Deccio > Internet-Draft Verisign Labs > Intended status: Informational J. Levine > Expires: September 10, 2015 Taughannock Networks > March 9, 2015 > > > Concepts for Domain Name Relationships > draft-deccio-domain-name-relationships-00 > > Abstract > > Various Internet protocols and applications require some mechanism > for identifying relationships between Domain Name System (DNS) names. > In this document we provide examples of protocols and applications > for which knowledge of these relationships is useful, if not > required. Further we discuss the various types of domain name > relationships, review current needs and solutions, and identify > considerations for solution sets. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Domain Name Concepts . . . . . . . . . . . . . . . . . . . . . 3 > 2.1. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.2. Domain Name Scope . . . . . . . . . . . . . . . . . . . . 4 > 2.2.1. Public/private Boundaries . . . . . . . . . . . . . . 4 > 2.3. Domain Name Relationships . . . . . . . . . . . . . . . . 4 > 3. Policy-based Domain Name Relationships . . . . . . . . . . . . 5 > 3.1. Cross-Scope Policy Relationships . . . . . . . . . . . . . 5 > 3.2. Intra-Scope Policy Relationships . . . . . . . . . . . . . 5 > 3.2.1. Public-public Policy Relationships . . . . . . . . . . 6 > 3.2.2. Private-private Policy Relationships . . . . . . . . . 6 > 4. Known Applications Requiring Identification of > Policy-based Domain Relationships . . . . . . . . . . . . . . 6 > 4.1. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.2. Email sender verification . . . . . . . . . . . . . . . . 7 > 4.3. SSL certificate requests . . . . . . . . . . . . . . . . . 7 > 5. Public Suffix List . . . . . . . . . . . . . . . . . . . . . . 8 > 5.1. Known Application Usage . . . . . . . . . . . . . . . . . 9 > 6. Solution Considerations . . . . . . . . . . . . . . . . . . . 9 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 > 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 > > > > 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 identify relationships between arbitrary domains. > > We begin by establishing terminology and concepts, after which we > discuss known applications for which the identification of domain > name relationships are desirable or required. We then discuss the > Public Suffix List, the primary solution for domain relationships > currently available. Finally, we recommend considerations for > solutions in this problem space. > > > 2. Domain Name Concepts > > For consistency in language we define terms and concepts surrounding > domain names. > > 2.1. Domain Names > > A DNS domain name is represented as sequence of dot-separated labels, > such as www.example.com (i.e., comprised of labels "www", "example", > and "com"). This sequence corresponds to the list of the labels > formed by traversing the tree representing the domain name space, > from the node representing the name itself to the root (top) of the > tree ([RFC1034]). In this tree context, we thus refer to domain > name's parent as the domain name formed by removing the leftmost > label (i.e., the domain name corresponding to the node directly above > it in the tree). The parent of www.example.com is example.com. > > As there are no requirements or inferences surrounding delegation > (i.e., zone cut) at any point in the DNS tree, there are no > assumptions in this document about administrative boundaries drawn by > delegations, unless explicitly stated otherwise. That is to say that > this document considers DNS names independently from their > administration, as defined by the DNS. suggest: That is to say: this document considers DNS names independently from their DNS-specific technical administration. > As noted in [RFC1034], the term "domain name" is used in contexts > outside the DNS. The scope of this document is limited to domain > names as defined by the DNS. aside: is there an RFC for "the DNS" that is equivalent to, say, RFC3377 (which defined the LDAPv3 spec set) ? > 2.2. Domain Name Scope > > The use of domain names in various applications over time has > produced a notion of scope, which we use to refer to the general > ability of arbitrary entities to register children of a domain name > (i.e., create child nodes in the domain name tree). In some contexts > these are called "public suffixes" or "registry controlled domains" s/contexts/contexts,/ s/called/referred to as/ > ([RFC6265]). For example, children of the top-level domain (TLD) > com, are generally registrable by arbitrary entities, which puts the > com domain name in the public scope. However, com's children are > typically not used in the same fashion (though certainly there are > exceptions), which puts them largely in the private scope. need more thoroughly defined notion of public & private because there are so many shades of grey in between them -- the diff is actually more which registry controls particular portions of the namespace, its policies, and who administers it aka "policy authority {realm,domain,range,scope,..}" i.e., declaring this particular scope dimension as simply public or private is too coarse grained and potentially misleading domain registry scope == policy realm (see [1]) > > The children of public domain names may either be in public or > private scope; likewise the children of private domain names may > either be in public or private scope. suggest: The children of names in one policy realm may either be within the same policy realm or a different policy realm. "scope" seems to be essentially be used as "policy realm" [1] > > While zone cuts often exist along public/private scope boundaries > (e.g., between com and example.com), they are not required at these > boundaries, nor are scope boundaries required at zone cuts. suggest: While zone cuts often exist along policy realm boundaries (e.g., between com and example.com), they are not required at these boundaries, nor are policy realm boundaries required at zone cuts. > In this > document public/private scope is considered independent of > administrative boundaries defined by the DNS (i.e., zone cuts). suggest: In this document, policy realm boundary extent is considered independent of DNS technical administration (e.g., zone cuts). > > The most well-known delineator of public/private scope is the Public > Suffix List (PSL) [PSL], which is described later in this document. It is quite unfortunate that the term "effective TLD" was supplanted by "public suffix" -- and even effective TLD is too coarse of a term for what it effectively represents > 2.2.1. Public/private Boundaries > > If we consider the root domain name itself to be public, then between > the root domain name and any private domain name (below), there must > exist at least one boundary going from some public parent to private > child. The first such boundary encountered upon downward traversal > from the root is the first-level public boundary. Subsequent public- > to-private boundaries are referred to as lower-level public > boundaries. For example, because the com domain name is considered > public, if we assume that example.com is private, then the first- > level public boundary is between com and example.com. If the > public.example.com domain name is considered public (i.e., children > domain names can be registered by arbitrary third parties) and > foo.public.example.com is a private domain name, then a lower-level > public boundary exists between public.example.com and > foo.public.example.com. having discussion of the fact as one traverses the DNS tree, one will traverse policy realm boundaries is useful using the "public" vs "private" coarse distinction is however, misleading and seriously glosses over the necessary-to-understand nuance that there can be very fine-grained yet distinct and important differences between the registry policies of one policy realm to another policy realm yes, anyone may /attempt/ to register a label directly under the root, hence it might seem "public", but doing so is strictly controlled by a large and complex set of policies administered by ICANN, and one is not guaranteed to pass muster and have their desired name (and associated namespace management policies) accepted by ICANN -- thus simply referring to the namespace one level below the root as just a "policy realm" is more generic and the term can be used to refer to any policy/governance/registry boundary anywhere in the dns namespace (aka tree). > > 2.3. Domain Name Relationships > > In this document two types of domain name relationships are > identified: ancestry and policy. An ancestral relationship exists > between two domains if one domain name is an ancestor of the other. why introduce yet another term ie "ancestor" ? above, the terminology is parent / child > > > A policy relationship exists between two domain names if their > relationship is such that application policy should treat them as > equivalent. For example, the two names might be administered by the > operating organization, or there might business or other > relationships between the two operating entities. clean up above > > In the simplest case, two domain names might be policy-related for > all applications or purposes. However, it is possible that two > domains are related only for explicitly defined purposes. > > An ancestral relationship between two names can be identified merely > by comparing the names themselves to determine whether one is a > substring of the other. However, there is no inherent way to > determine policy relationships neither by examination of the names > themselves, nor by examining the administrative boundaries (i.e., > zone cuts) defined in the DNS. This is the problem being considered > in this document. clean up above > 3. Policy-based Domain Name Relationships > > Because policy-based domain name relationships are not inherently > apparent based on the names themselves or DNS protocol, mechanisms > outside the DNS namespace and base protocol are necessary to > advertise and detect those relationships. ?? > > In this section we enumerate the different types of ancestral and > scope relationships upon which policy-based relationships can be > overlaid. > > 3.1. Cross-Scope Policy Relationships > > If scope of one domain name is public and another is private, then it > can be inferred, by the definition of their respective scopes, that > there exists no policy-based relationship between the two. That is, > a public domain name cannot be related, for policy purposes, to a > private domain name. > > Note that this doesn't prohibit policy relationships between two > domain names of the same scope but having (an even number) of scope > boundaries in between. public/private is too coarse-grained > > 3.2. Intra-Scope Policy Relationships > > We now consider the existence of a policy relationship between two > domains names of the same scope. > > > > > > Deccio & Levine Expires September 10, 2015 [Page 5] > > Internet-Draft Concepts for Domain Name Relationships March 2015 > > > 3.2.1. Public-public Policy Relationships > > The connotation of a public domain name in the context of policy is > that it should not be used for purposes normally associated with > private domain names. For example, it would be unreasonable to > expect legitimate mail to come from an email address having the exact > suffix of org.au (a domain name currently identified by [PSL] as > being public). This is especially true of domain names above the > first-level public boundary. why? could not the administrators of a particular policy realm, even a single-label one, cause email (eg theirs) to be sent "from" an address at that single-label policy realm? also are not single-label domains emerging in real fact? > > Because of this connotation, one consideration for policy amongst two > domain names, both public, is that no effective relationship exists > because they are ineligible by definition. Other than that, there is > insufficient information from only domain names and scope alone to > confirm or deny a policy relationship. > > 3.2.2. Private-private Policy Relationships > > There are two classes of potential private-private policy > relationships: ancestral and cross-domain (non-ancestral). In > neither case can the presence or absence of a policy relationship be > confirmed using only the names and scope information. what scope information? > > > 4. Known Applications Requiring Identification of Policy-based Domain > Relationships > > In this section we discuss the current state of known applications > requiring identification of policy-based domain name relationships. > > 4.1. HTTP Cookies > > Domain names are used extensively in conjunction with the Hypertext > Transfer Protocol (HTTP) ([RFC7230], [RFC7231]). The domain names > used in Uniform Resource Identifiers (URIs) [RFC3986] are used by > HTTP clients not only for resolution to an HTTP server Internet > Protocol (IP) address, but also for enforcing policy. > > HTTP clients maintain local state in the form of key/value pairs s/local state/application state/ establishing such state is directed by the server > known as cookies ([RFC6265]). While most often cookies are initially > set by HTTP servers, HTTP clients send all cookies in HTTP requests > for which the domain name in the URI is within the cookies' scope. > The scope of a cookie is defined using a domain name in the "domain" > attribute of the cookie. When a cookie's "domain" attribute is > specified as a domain name (as opposed to an IP address), the domain > name in the URL is considered within scope if it is a descendant of > the "domain" attribute. hm need to check 6265 > RFC 2965 [RFC2965] (now obsolete) required that the value of the > "domain" field carry at least one embedded dot. This was to prohibit > TLDs--which were almost exclusively public--from being associated, by > policy, with other domains. Cookies having public scope would enable > the association of HTTP requests across different, independently > operated domains, which policy association raises concerns of user > privacy and security. > > In the current specification ([RFC6265]), the semantic requirements > were modified to match "public suffixes" because it was recognized > that TLDs are not the only domain names with public scope--and that > not all TLDs are public suffixes. The notion that all TLDs are > inherently public has been challenged by the many and diverse domain > names that have been delegated since 2013 as part of the new generic > top-level domain (gTLD) program ([NewgTLDs]). the latter is correct, tho am not sure of reason to explain this distinction in this way. the latter paragraph illustrates the more fine-grained distinctions between policy realms rather than using the coarse terms public/private. > > 4.2. Email sender verification > > An emerging sender verification called Domain-based Message s/sender/email sender/ > Authentication, Reporting and Conformance (DMARC) > [I-D.kucherawy-dmarc-base] attempts to validate the domain name of > the author's address on the message's "From:" header using the > DomainKeys Identified Email (DKIM) [RFC5585] and Sender Policy > Framework (SPF) [RFC7208] 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's bounce address is validated. DMARC allows > approximate matching between the author's domain and the validated > domain name, where one can be an ancestor or descendant of the other. > > DMARC validators are supposed to ensure that the two domain names are > under the same management, the specifics of which are deliberately > left out of the spec. thus having a need for discerning policy realms > > 4.3. SSL certificate requests s|SSL|TLS/SSL| globally > > 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 (CA/B > Ballot 74 [CA/B-Ballot-74]). referencing a ballot in a non-open org? why not the BRs ? > 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 name, the entire > range of names covered by the wildcard needs to be under the same > control. ..and thus having a means to ascertain this would be useful > Authorities do not (knowingly) issue certificates for > public domain names such as *.org.au. what is the distinction/implication of the latter name? > > 5. Public Suffix List > > The most well-known resource currently available for identifying > public domain names is the Public Suffix List (PSL) [PSL]. The PSL > is explicitly referenced as an example of an up-to-date public suffix > list in [RFC6265]. well, more or less up-to-date > The PSL was developed by Mozilla Firefox > developers to further address HTTP security and privacy concerns > surrounding cookie scope when the "no embedded dot" rule of [RFC2965] > was the upper limit. > > The PSL contains a list of known public suffixes, and includes > placeholder public domains designated by "wildcard" notation in the > file. A wildcard implies that all children of the wildcard's parent > are in fact public domain names themselves--except where otherwise > noted as a wildcard exception. For example, we use the contrived > entries in Table 1 to demonstrate this use of the PSL. > > +--------------+------------------------------------+ > | Entry | Meaning | > +--------------+------------------------------------+ > | example | example is public | > | *.example | All children of example are public | > | !foo.example | foo.example is private | > +--------------+------------------------------------+ > > Table 1: Contrived PSL Entries > > 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 | > +---------------------+---------+ > > Domain name scope based on the PSL entries from Table 1. > > Table 2: Contrived PSL Entries > > The PSL effectively identifies scope, insomuch as the list is s/scope/policy authority realm boundaries/ > accurate. Of the 6,823 entries in the PSL at the time of this > writing, all but 50 are used to designate first-level public > boundaries; the remainder designate lower-level boundaries. The > > > > Deccio & Levine Expires September 10, 2015 [Page 8] > > Internet-Draft Concepts for Domain Name Relationships March 2015 > > > primary function of the PSL, therefore, is to delineate first-level > public boundaries. uh, but that's "today" -- it will evolve as the DNS namespace evolves > > Matters of policy that can be settled simply by identifying the scope > of the names in question are thus addressed by the PSL. However, the > question of determining whether a policy-based relationship between > intra-scope names (with the possible exception of those of public > scope) are unaddressed. too coarse > > 5.1. Known Application Usage > > The PSL is used by several browsers, including Mozilla Firefox, to > identify domain names 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 (i.e., the child of the domain name's nearest > public ancestor). This is useful for organizing names and URIs by > domain name, as in bookmarks, and for highlighting key parts of URIs > or certificates in the address bar or other parts of the browser > interface. > > Existing DMARC implementations are known to use the PSL to assert > policy-based relationships between SPF- or DKIM-authenticated > validated domain names and domain name corresponding to the address > in the "From:" header. Such a relationship is identified if two > domain names are both of private scope and share an ancestral > relationship. > > DMARC implementations also use the PSL 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 domain names having public scope. > > > 6. Solution Considerations > > The problem discussed in this document is the association of domain > names for policy purposes. The PSL has been the de-facto > supplementary resource utilized for identifying such relationships. > The shortcomings of only having domain names and their scope (e.g., > via the PSL) have been treated in Section Section 5. > > An alternate paradigm for addressing the problem involves a system > > > > Deccio & Levine Expires September 10, 2015 [Page 9] > > Internet-Draft Concepts for Domain Name Relationships March 2015 > > > wherein policy-based relationships are explicitly defined on a per- > domain name (pair) basis. For scalability and dynamic response this > is most effectively achieved through defining these relationships in > the DNS itself, e.g., through special records included in the DNS at > (or near) the domain names themselves, such as the mechanism proposed > in [I-D.sullivan-domain-origin-assert]. > One benefit to this paradigm > is that it allows the definition of policy-based relationships > between arbitrary names at any locations in the DNS domain name tree, > and the notion of scope becomes moot. Another benefit is that it > puts the definition of those relationships in the hands of the > administrators and operators of the domain names themselves, rather > than a third party. > > There are several challenges with the domain name-centric paradigm as > well. One challenge is that it requires correct, consistent, and > coordinated efforts by affected domain name operators. The number of > involved parties, moving parts, and dependencies introduces more > chance for error. Additionally, having the information available > online (e.g., in the DNS) means that consumption by local > applications is dependent on real-time Internet connectivity, which > is not always possible nor desirable. > > Another solution set is that which includes both a scope definition > resource (e.g., the PSL) and a mechanism for explicit definition of > policy-based relationships on a per-domain name basis. In this case > the scope definitions are consulted first to determine whether a > policy-based relationship is possible, after which (if necessary) > special domain name-specific lookups are issued to further determine > whether such a relationship exists. This addresses what might be the > most common issues using a central, relatively simple, and > established mechanism, leaving the flexibility for additional > extensibility with domain name-specific relationship definitions. > > We recommend that the cost and the value of the different solution > paradigms be considered when developing solutions for the problem of > defining policy-based relationships between domain names. As part of > this, the model of domain name relationships outlined in Section > Section 2.3 should be analyzed to consider which types of > relationships are most in demand, and which solutions are sufficient > for the circumstances in highest demand. Such will enable an > appropriate and usable balance of efficiency, robustness, > flexibility, and autonomy. > > > 7. IANA Considerations > > This document includes no requests for IANA. > > > > > Deccio & Levine Expires September 10, 2015 [Page 10] > > Internet-Draft Concepts for Domain Name Relationships March 2015 > > > 8. Security Considerations > > This document does not specify a protocol or usage and, therefore, > there are no new security considerations for it. There are security > considerations for major cases in which domain boundaries are used, > such as HTTP Cookies and DMARC, both discussed here. See the > Security Considerations of RFC 6265 [RFC6265] and > [I-D.kucherawy-dmarc-base]. > > > 9. Informative References > > [CA/B-Ballot-74] > Certificate Authority(CA)/Browser Forum, "Ballot 74", > 2015, ballot-74-updates-to-domain-and-ip-validation-high-risk- > requests-and-data-source-in-the-baseline-requirements/>. > > [I-D.kucherawy-dmarc-base] > Kucherawy, M. and E. Zwicky, "Domain-based Message > Authentication, Reporting and Conformance (DMARC)", > draft-kucherawy-dmarc-base-13 (work in progress), > February 2015. > > [I-D.sullivan-domain-origin-assert] > Sullivan, A., "Asserting DNS Administrative Boundaries > Within DNS Zones", draft-sullivan-domain-origin-assert-02 > (work in progress), October 2012. > > [NewgTLDs] > ICANN, "New Generic Top-Level Domains", 2015, > . > > [PSL] Mozilla Foundation, "Public Suffix List", 2015, > . > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management > Mechanism", RFC 2965, October 2000. > > [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifier (URI): Generic Syntax", STD 66, > RFC 3986, January 2005. > > [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys > Identified Mail (DKIM) Service Overview", RFC 5585, > > > > Deccio & Levine Expires September 10, 2015 [Page 11] > > Internet-Draft Concepts for Domain Name Relationships March 2015 > > > July 2009. > > [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, > April 2011. > > [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for > Authorizing Use of Domains in Email, Version 1", RFC 7208, > April 2014. > > [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol > (HTTP/1.1): Message Syntax and Routing", RFC 7230, > June 2014. > > [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol > (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. > > > Authors' Addresses > > Casey Deccio > Verisign Labs > 12061 Bluemont Way > Reston, VA 20190 > USA > > Phone: +1 703-948-3200 > Email: cdeccio@verisign.com > > > John Levine > Taughannock Networks > PO Box 727 > Trumansburg, NY 14886 > > Phone: +1 831 480 2300 > Email: standards@taugh.com > URI: http://jl.ly > > > > > > > > > > > > > > > Deccio & Levine Expires September 10, 2015 [Page 12] > From nobody Mon Mar 23 11:45:15 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671A21AD333 for ; Mon, 23 Mar 2015 11:45:13 -0700 (PDT) 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 IZwm7s6oOXCU for ; Mon, 23 Mar 2015 11:45:11 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4B31AD33B for ; Mon, 23 Mar 2015 11:45:11 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so46921020igb.1 for ; Mon, 23 Mar 2015 11:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dTY/2Nq+f92RG7IR6eKoHOPnS6gMf891DNESKXVoOe0=; b=NybkXBJsWZuwKm4RJ5Gpoy4zSHO9kjZeCGf7HXkSM1Z6v1vEeWyz9ij3KgSLSvuay3 x2jJe1KiUXgms3eS4AZ31yn0Z9cO7ZRWV5Po02GiH0F20CyMlJZ3mL+1+ZiMXQ4gFXT6 YvEKkuHsbUfy+ULECaFi0DbakpyXePD3D7N+o= 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=dTY/2Nq+f92RG7IR6eKoHOPnS6gMf891DNESKXVoOe0=; b=dz/hTvAWttaBpHmzSF2AJs8G+oqaRwL2X4uXXwpoQXclwawiyl5HTJZxsUW60rVRMn zvtXUl+QlzUsSVMW7x8h1kylLxa4tYEBg3ligcWphJZOAQdkBA2R26K4tjERhlIBiokZ gf2e8Yp46gRCskwq406NbzHoDnxASg+YOtEan9OK+qyxSgOUtSNrHyv5BUHmAq7ti+tH ZxG/PRHFJzh0+377+TZ10ZimwqTrWqHz9ZYZR/JvyVZuvniBE++EVbP9ZrDrITUn+nbk mCLAxLujyt2yzq6LOOBdZ2e0vXcy/uz7tvLwt8t4HI8YJCaxDprHnI0AwuMn14E0Asuq LSFQ== X-Gm-Message-State: ALoCoQm7wvQuLBWs5jsB1dMhLBb6x3xa0Bv5MRh5u/A8yOn2TEx9Lam/IQiAkBixY8+LVBPQ0jtH MIME-Version: 1.0 X-Received: by 10.107.25.68 with SMTP id 65mr998573ioz.44.1427136310651; Mon, 23 Mar 2015 11:45:10 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Mon, 23 Mar 2015 11:45:10 -0700 (PDT) Date: Mon, 23 Mar 2015 14:45:10 -0400 Message-ID: From: Casey Deccio To: "=JeffH" Content-Type: multipart/alternative; boundary=001a113fe548d7c2bb0511f91056 Archived-At: Cc: "dbound@ietf.org" Subject: [dbound] public/private vs. policy domain (comments on draft-deccio-domain-name-relationships-00) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:45:13 -0000 --001a113fe548d7c2bb0511f91056 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 12:53 PM, =JeffH wrote: > > overall, I am curious about the focus on "public" vs "private" in > draft-deccio-domain-name-relationships-00, and how the latter doc might > relate to draft-sullivan-dbound-problem-statement-00 [0] ? > Hi Jeff, Thanks for looking this over and providing comments. In this response, I address the above concern, which is the basis of many of your comments. If I understand correctly, there is a misunderstanding that the domain-name-relationships draft is attempting to align scope (i.e., public/private) with policy or even establish an equivalence between the two. If that misunderstanding is the case, let me clear that up. The purpose of the draft is to establish background: domain name concepts, including namespace and scope; known policy use of domain names; current use of the PSL to perform policy functions based on scope. However, it is not meant to draw an equivalence between scope (or any other name/namespace concept for that matter) and policy domain. See, for example, section 3, which discusses policy relationships within scope and across scope boundaries. In other words, it recognizes that scope exists, and that scope boundaries are being used for policy purposes (e.g., based on the PSL's definition of scope), but its intent is not to advocate policy relationships based on scope or namespace. Regards, Casey --001a113fe548d7c2bb0511f91056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 23, 2015 at 12:53 PM, =3DJeffH <J= eff.Hodges@kingsmountain.com> wrote:

overall, I am curious about the focus on "public" vs "privat= e" in draft-deccio-domain-name-relationships-00, and how the latter do= c might relate to draft-sullivan-dbound-problem-statement-00 [0] ?

Hi Jeff,

Thanks for looking t= his over and providing comments.=C2=A0 In this response, I address the abov= e concern, which is the basis of many of your comments.=C2=A0 If I understa= nd correctly, there is a misunderstanding that the domain-name-relationship= s draft is attempting to align scope (i.e., public/private) with policy or = even establish an equivalence between the two.=C2=A0 If that misunderstandi= ng is the case, let me clear that up.=C2=A0 The purpose of the draft is to = establish background: domain name concepts, including namespace and scope; = known policy use of domain names; current use of the PSL to perform policy = functions based on scope.=C2=A0 However, it is not meant to draw an equival= ence between scope (or any other name/namespace concept for that matter) an= d policy domain.=C2=A0 See, for example, section 3, which discusses policy = relationships within scope and across scope boundaries.=C2=A0 In other word= s, it recognizes that scope exists, and that scope boundaries are being use= d for policy purposes (e.g., based on the PSL's definition of scope), b= ut its intent is not to advocate policy relationships based on scope or nam= espace.

Regards,
Casey
--001a113fe548d7c2bb0511f91056-- From nobody Mon Mar 23 12:57:40 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5501A0282 for ; Mon, 23 Mar 2015 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAgw1bbGh51d for ; Mon, 23 Mar 2015 12:57:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574241A046D for ; Mon, 23 Mar 2015 12:57:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323195734.2739.3363.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 12:57:34 -0700 From: IETF Secretariat Archived-At: Subject: [dbound] State changed: charter-ietf-dbound-00-03 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:57:39 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-dbound/ From nobody Mon Mar 23 12:58:35 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256B1A03E3 for ; Mon, 23 Mar 2015 12:58:34 -0700 (PDT) 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 IYXYnmh2L1NK for ; Mon, 23 Mar 2015 12:58:32 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0621A040B for ; Mon, 23 Mar 2015 12:58:31 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so51259782ied.1 for ; Mon, 23 Mar 2015 12:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JPKrDOrh7onHqf3BX4gATq+Su1RgOrM06J7hacHdUHw=; b=Z4jr1T0ZBKiSqwOH9RlUmU0Mr106QVWhwHild3mFHP7+St33XAbEvFs1meJg8uLwju /EYMenUu/xN736Zs/j0Mzx+BPfG0KLw+cDCZPL0TT47dFrjr7Fr6YZsJAKkZ9/H5K6Sd gPtRwIl8uZQhwYqznjtj7LL4aBQCxDGnUssSM= 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=JPKrDOrh7onHqf3BX4gATq+Su1RgOrM06J7hacHdUHw=; b=TOuc7om8lLrXc1jOHKWwakd2j6JBuXROpM8mA2wwg8rY75BeNPQSMHCqRpQLNyWrpV R06R67i/cmoijElGeFEEuuFfgn/D70xmrAKKtcyrxtUTtTqsirZSyAPBWKLDBOt491vo QjRBe8S+KsqGpWwDNrtoYmZ4xg6zHaH2S8dslff61OjfJFbyGxOT3tnnUQTjx9CxqnNS FoQ01DI4TkHbsNAOYby58wi+bYnv9rMoCyS9nNR/Dazi41ck9sVjU+3w7p7xgTmhYh3W squdEQVqP1/vX4N83F2Zdgq00KX2AnoUgLIGyzUUf2zRJFxPz/Tj/LKjg+twkZprz8cO IZOA== X-Gm-Message-State: ALoCoQlzSRQt4Pr/VMuqPVfWyHldUT24Hd8XTuEBnxYcbJmHAo1R6dk2ikpHD1AR+ToL8ridavAq MIME-Version: 1.0 X-Received: by 10.50.254.99 with SMTP id ah3mr16995443igd.12.1427140711285; Mon, 23 Mar 2015 12:58:31 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Mon, 23 Mar 2015 12:58:31 -0700 (PDT) In-Reply-To: <55104501.3070906@KingsMountain.com> References: <55104501.3070906@KingsMountain.com> Date: Mon, 23 Mar 2015 15:58:31 -0400 Message-ID: From: Casey Deccio To: "=JeffH" Content-Type: multipart/alternative; boundary=001a1134a90e241ea70511fa17ea Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:58:34 -0000 --001a1134a90e241ea70511fa17ea Content-Type: text/plain; charset=UTF-8 Thanks for the comments. Those not implicitly addressed by the public/private scope commentary in the forked thread or otherwise necessitating additional commentary are addressed below. Thanks, Casey > 3.2.1. Public-public Policy Relationships > > > > The connotation of a public domain name in the context of policy is > > that it should not be used for purposes normally associated with > > private domain names. For example, it would be unreasonable to > > expect legitimate mail to come from an email address having the exact > > suffix of org.au (a domain name currently identified by [PSL] as > > being public). This is especially true of domain names above the > > first-level public boundary. > > why? could not the administrators of a particular policy realm, even a > single-label one, cause email (eg theirs) to be sent "from" an address at > that single-label policy realm? > Again - we're not talking about policy realms. This is a discussion of public-scoped names, which by definition, have certain distinction, in terms of their use and constraints, from private names. > also are not single-label domains emerging in real fact? > Note that I explicitly challenge the notion that a single label implies public (or that public implies single-label, for that matter. > 3.2.2. Private-private Policy Relationships > > > > There are two classes of potential private-private policy > > relationships: ancestral and cross-domain (non-ancestral). In > > neither case can the presence or absence of a policy relationship be > > confirmed using only the names and scope information. > > what scope information? > The fact that they are both private--probably needs a parenthetical to this effect. > > known as cookies ([RFC6265]). While most often cookies are initially > > set by HTTP servers, HTTP clients send all cookies in HTTP requests > > for which the domain name in the URI is within the cookies' scope. > > The scope of a cookie is defined using a domain name in the "domain" > > attribute of the cookie. When a cookie's "domain" attribute is > > specified as a domain name (as opposed to an IP address), the domain > > name in the URL is considered within scope if it is a descendant of > > the "domain" attribute. > > > hm need to check 6265 > > This is probably simplistic, and more language from RFC 6265 sections 5.3 and 5.4 should probably be integrated. > > RFC 2965 [RFC2965] (now obsolete) required that the value of the > > "domain" field carry at least one embedded dot. This was to prohibit > > TLDs--which were almost exclusively public--from being associated, by > > policy, with other domains. Cookies having public scope would enable > > the association of HTTP requests across different, independently > > operated domains, which policy association raises concerns of user > > privacy and security. > > > > In the current specification ([RFC6265]), the semantic requirements > > were modified to match "public suffixes" because it was recognized > > that TLDs are not the only domain names with public scope--and that > > not all TLDs are public suffixes. The notion that all TLDs are > > inherently public has been challenged by the many and diverse domain > > names that have been delegated since 2013 as part of the new generic > > top-level domain (gTLD) program ([NewgTLDs]). > > the latter is correct, tho am not sure of reason to explain this > distinction in this way. the latter paragraph illustrates the more > fine-grained distinctions between policy realms rather than using the > coarse terms public/private. > > scope != policy domain > > 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 (CA/B > > Ballot 74 [CA/B-Ballot-74]). > > referencing a ballot in a non-open org? why not the BRs ? > If you have a better reference, I'm happy to substitute. The use cases are more valuable the more specific they are. > > Authorities do not (knowingly) issue certificates for > > public domain names such as *.org.au. > > what is the distinction/implication of the latter name? > > That it is a public name (as defined in the PSL) and is used earlier in the document as an example of such. I can use another parenthetical to remind the reader of that. > > The most well-known resource currently available for identifying > > public domain names is the Public Suffix List (PSL) [PSL]. The PSL > > is explicitly referenced as an example of an up-to-date public suffix > > list in [RFC6265]. > > well, more or less up-to-date > > The intent of the carefully-worded statement above is not to support or refute the statement from RFC 6265, but simply to reference it. > accurate. Of the 6,823 entries in the PSL at the time of this > > writing, all but 50 are used to designate first-level public > > boundaries; the remainder designate lower-level boundaries. The > > primary function of the PSL, therefore, is to delineate first-level > > public boundaries. > > uh, but that's "today" -- it will evolve as the DNS namespace evolves > That's speculative, but 1) yes, the statement represents the primary function of the PSL both currently (i.e., "today") and for the foreseeable future; and 2) its evolution would be based on the evolution of the *use* of the DNS namespace. Remember the distinction is about first-level vs. lower-level boundary identification. > > Matters of policy that can be settled simply by identifying the scope > > of the names in question are thus addressed by the PSL. However, the > > question of determining whether a policy-based relationship between > > intra-scope names (with the possible exception of those of public > > scope) are unaddressed. > > too coarse > Could you please be more specific? --001a1134a90e241ea70511fa17ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comments.=C2=A0 Those not implici= tly addressed by the public/private scope commentary in the forked thread o= r otherwise necessitating additional commentary are addressed below.
Thanks,
Casey

> 3.2.1.=C2=A0 Public-pub= lic Policy Relationships
>
>=C2=A0 =C2=A0 The connotation of a public domain name in the context of= policy is
>=C2=A0 =C2=A0 that it should not be used for purposes normally associat= ed with
>=C2=A0 =C2=A0 private domain names.=C2=A0 For example, it would be unre= asonable to
>=C2=A0 =C2=A0 expect legitimate mail to come from an email address havi= ng the exact
>=C2=A0 =C2=A0 suffix of org.au (a domain name currently identified by [= PSL] as
>=C2=A0 =C2=A0 being public).=C2=A0 This is especially true of domain na= mes above the
>=C2=A0 =C2=A0 first-level public boundary.

why?=C2=A0 could not the administrators of a particular policy realm, even = a single-label one, cause email (eg theirs) to be sent "from" an = address at that single-label policy realm?

<= div>Again - we're not talking about policy realms.=C2=A0 This is a disc= ussion of public-scoped names, which by definition, have certain distinctio= n, in terms of their use and constraints, from private names.

=

also are not single-label domains emerging in real fact?

Note that I explicitly challenge the notion that a single= label implies public (or that public implies single-label, for that matter= .

> 3.2.2.=C2=A0 Private-private Policy Relationships
>
>=C2=A0 =C2=A0 There are two classes of potential private-private policy=
>=C2=A0 =C2=A0 relationships: ancestral and cross-domain (non-ancestral)= .=C2=A0 In
>=C2=A0 =C2=A0 neither case can the presence or absence of a policy rela= tionship be
>=C2=A0 =C2=A0 confirmed using only the names and scope information.

what scope information?

The fact that t= hey are both private--probably needs a parenthetical to this effect.
=C2= =A0
>=C2=A0 =C2=A0 known as cookies ([RFC6265]).=C2=A0 While most often cook= ies are initially
>=C2=A0 =C2=A0 set by HTTP servers, HTTP clients send all cookies in HTT= P requests
>=C2=A0 =C2=A0 for which the domain name in the URI is within the cookie= s' scope.
>=C2=A0 =C2=A0 The scope of a cookie is defined using a domain name in t= he "domain"
>=C2=A0 =C2=A0 attribute of the cookie.=C2=A0 When a cookie's "= domain" attribute is
>=C2=A0 =C2=A0 specified as a domain name (as opposed to an IP address),= the domain
>=C2=A0 =C2=A0 name in the URL is considered within scope if it is a des= cendant of
>=C2=A0 =C2=A0 the "domain" attribute.


hm need to check 6265


This is probably simplistic, and more = language from RFC 6265 sections 5.3 and 5.4 should probably be integrated.<= br>=C2=A0
>=C2=A0 =C2=A0 RFC 2965 [RFC2965] (now obsolete) required that the value= of the
>=C2=A0 =C2=A0 "domain" field carry at least one embedded dot.= =C2=A0 This was to prohibit
>=C2=A0 =C2=A0 TLDs--which were almost exclusively public--from being as= sociated, by
>=C2=A0 =C2=A0 policy, with other domains.=C2=A0 Cookies having public s= cope would enable
>=C2=A0 =C2=A0 the association of HTTP requests across different, indepe= ndently
>=C2=A0 =C2=A0 operated domains, which policy association raises concern= s of user
>=C2=A0 =C2=A0 privacy and security.
>
>=C2=A0 =C2=A0 In the current specification ([RFC6265]), the semantic re= quirements
>=C2=A0 =C2=A0 were modified to match "public suffixes" becaus= e it was recognized
>=C2=A0 =C2=A0 that TLDs are not the only domain names with public scope= --and that
>=C2=A0 =C2=A0 not all TLDs are public suffixes.=C2=A0 The notion that a= ll TLDs are
>=C2=A0 =C2=A0 inherently public has been challenged by the many and div= erse domain
>=C2=A0 =C2=A0 names that have been delegated since 2013 as part of the = new generic
>=C2=A0 =C2=A0 top-level domain (gTLD) program ([NewgTLDs]).

the latter is correct, tho am not sure of reason to explain this distinctio= n in this way.=C2=A0 the latter paragraph illustrates the more fine-grained= distinctions between policy realms rather than using the coarse terms publ= ic/private.


scope !=3D policy domain
=C2=A0
=
>=C2=A0 =C2=A0 Secure Socket Layer (SSL) certificate authorities typical= ly validate
>=C2=A0 =C2=A0 certificate signing requests by sending a confirmation me= ssage to one
>=C2=A0 =C2=A0 of the WHOIS contacts for the (private scope) domain name= (CA/B
>=C2=A0 =C2=A0 Ballot 74 [CA/B-Ballot-74]).

referencing a ballot in a non-open org?=C2=A0 why not the BRs ?

If you have a better reference, I'm happy to s= ubstitute.=C2=A0 The use cases are more valuable the more specific they are= .
=C2=A0
>= Authorities do not (knowingly) issue certificates for
>=C2=A0 =C2=A0 public domain names such as *.org.au.

what is the distinction/implication of the latter name?


That it is a public name (as defined i= n the PSL) and is used earlier in the document as an example of such.=C2=A0= I can use another parenthetical to remind the reader of that.
=C2=A0
>=C2=A0 =C2=A0 The most well-known resource currently available for iden= tifying
>=C2=A0 =C2=A0 public domain names is the Public Suffix List (PSL) [PSL]= .=C2=A0 The PSL
>=C2=A0 =C2=A0 is explicitly referenced as an example of an up-to-date p= ublic suffix
>=C2=A0 =C2=A0 list in [RFC6265].

well, more or less up-to-date


The intent of the carefully-worded sta= tement above is not to support or refute the statement from RFC 6265, but s= imply to reference it.

>=C2=A0 =C2=A0 accurate.=C2=A0 Of the 6,8= 23 entries in the PSL at the time of this
>=C2=A0 =C2=A0 writing, all but 50 are used to designate first-level pub= lic
>=C2=A0 =C2=A0 boundaries; the remainder designate lower-level boundarie= s.=C2=A0 The
>=C2=A0 =C2=A0 primary function of the PSL, therefore, is to delineate f= irst-level
>=C2=A0 =C2=A0 public boundaries.

uh, but that's "today" -- it will evolve as the DNS namespace= evolves

That's speculative, but 1)= yes, the statement represents the primary function of the PSL both current= ly (i.e., "today") and for the foreseeable future; and 2)=C2=A0 i= ts evolution would be based on the evolution of the *use* of the DNS namesp= ace.=C2=A0 Remember the distinction is about first-level vs. lower-level bo= undary identification.
=C2=A0
>=C2=A0 =C2=A0 Matters of policy that can be settled simply by identifyi= ng the scope
>=C2=A0 =C2=A0 of the names in question are thus addressed by the PSL.= =C2=A0 However, the
>=C2=A0 =C2=A0 question of determining whether a policy-based relationsh= ip between
>=C2=A0 =C2=A0 intra-scope names (with the possible exception of those o= f public
>=C2=A0 =C2=A0 scope) are unaddressed.

too coarse

Could you please be more spe= cific?
--001a1134a90e241ea70511fa17ea-- From nobody Tue Mar 24 08:20:33 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144C71A88BD for ; Tue, 24 Mar 2015 08:20:29 -0700 (PDT) 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 4OmNBg5m1CbS for ; Tue, 24 Mar 2015 08:20:26 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA691A88B3 for ; Tue, 24 Mar 2015 08:20:25 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so190825igc.0 for ; Tue, 24 Mar 2015 08:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kbl8Dh+GZZMm8gMkFC4gG8JmecufvsS2LN9dPOcpwTY=; b=C2Yd/Ye65eH0Og+lhu5bn0t5Dr9oC7VlCQemhr8AsfczIRiWg+2e7gfwsCGJ09RHM8 HyS4kP2dGSlJUoLIPVYhWOvce09NF/v2Mj42rX9+tRUW1XOrrzu52I6BCw2BqNaf8kNX wSUFL5RnGHRg0fsb8fnwkwkU7bUQlJr3zrqjs= 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=Kbl8Dh+GZZMm8gMkFC4gG8JmecufvsS2LN9dPOcpwTY=; b=KNRMBd7XiCzPZqhowekZ8yYe07/VNN96cpZjI6+X8R3c572962J4XZTa4ASHVjteIk dGDduzHKx6IzRkx4Q7FplVkklI5s35fn7O1wwHw8BgciRj1D0MG1VsPn64A2uBYz3H/D n7qx4EDTZkiVv6hRolcwufZRgFcjGlPl1VIPzZdHSoaf4kRsLcd9yUWit2qp5bvgUvGS pTOT31B+PiXGjPvJCYZH/K3Pz3jPPhlcfO7ZI1+ZOKSZaiJL0Epv0hQpc8D8hM6fM2wS KXlGc4I0kbVf0QQNSEv3DcYRMDTWPsp2pQxey3ji3Y9Nfsjt9CDDaKoJt8BrP7E6D8Wy w89A== X-Gm-Message-State: ALoCoQl3g4oyzkOJEuPBhcTRUTsMVKiw5QPWdbCcS5lOkJlikY0b0MjMzY/z/H8yRE4ww16HCCKi MIME-Version: 1.0 X-Received: by 10.107.128.226 with SMTP id k95mr7096024ioi.73.1427210424008; Tue, 24 Mar 2015 08:20:24 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Tue, 24 Mar 2015 08:20:23 -0700 (PDT) In-Reply-To: <55104501.3070906@KingsMountain.com> References: <55104501.3070906@KingsMountain.com> Date: Tue, 24 Mar 2015 11:20:23 -0400 Message-ID: From: Casey Deccio To: "=JeffH" Content-Type: multipart/alternative; boundary=001a113f9ae457d92305120a52a9 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:20:29 -0000 --001a113f9ae457d92305120a52a9 Content-Type: text/plain; charset=UTF-8 I noticed that the first part of my response was accidentally omitted from the message that was actually sent, so I'm rewriting it here. Casey On Mon, Mar 23, 2015 at 12:53 PM, =JeffH wrote: > > As noted in [RFC1034], the term "domain name" is used in contexts > > outside the DNS. The scope of this document is limited to domain > > names as defined by the DNS. > > aside: is there an RFC for "the DNS" that is equivalent to, say, RFC3377 > (which defined the LDAPv3 spec set) ? > > RFC 1034/1035? > > ([RFC6265]). For example, children of the top-level domain (TLD) > > com, are generally registrable by arbitrary entities, which puts the > > com domain name in the public scope. However, com's children are > > typically not used in the same fashion (though certainly there are > > exceptions), which puts them largely in the private scope. > > need more thoroughly defined notion of public & private because there are > so many shades of grey in between them -- the diff is actually more which > registry controls particular portions of the namespace, its policies, and > who administers it aka "policy authority {realm,domain,range,scope,..}" > Could you explain what you mean by shades of grey? If it is grey, then it must not be public. See also the NOTE in bullet 5 of section 5.3 in RFC 6265. > i.e., declaring this particular scope dimension as simply public or > private is too coarse grained and potentially misleading > > domain registry scope == policy realm (see [1]) > The draft distinguishes between scope and policy relationships, and there is not an equivalence between the two. > > The most well-known delineator of public/private scope is the Public > > Suffix List (PSL) [PSL], which is described later in this document. > > > It is quite unfortunate that the term "effective TLD" was supplanted by > "public suffix" -- and even effective TLD is too coarse of a term for what > it effectively represents > There is a difference between what it *represents* and how it is being *used*. The PSL is a list defining suffixes known to be of public scope. When used (exclusively) as the basis for policy, then it can in fact be too coarse. > > 2.2.1. Public/private Boundaries > > > > If we consider the root domain name itself to be public, then between > > the root domain name and any private domain name (below), there must > > exist at least one boundary going from some public parent to private > > child. The first such boundary encountered upon downward traversal > > from the root is the first-level public boundary. Subsequent public- > > to-private boundaries are referred to as lower-level public > > boundaries. For example, because the com domain name is considered > > public, if we assume that example.com is private, then the first- > > level public boundary is between com and example.com. If the > > public.example.com domain name is considered public (i.e., children > > domain names can be registered by arbitrary third parties) and > > foo.public.example.com is a private domain name, then a lower-level > > public boundary exists between public.example.com and > > foo.public.example.com. > > > having discussion of the fact as one traverses the DNS tree, one will > traverse policy realm boundaries is useful > > using the "public" vs "private" coarse distinction is however, misleading > and seriously glosses over the necessary-to-understand nuance that there > can be very fine-grained yet distinct and important differences between the > registry policies of one policy realm to another policy realm > Let me reiterate that scope is not equivalent to policy realm. > > yes, anyone may /attempt/ to register a label directly under the root, > hence it might seem "public", but doing so is strictly controlled by a > large and complex set of policies administered by ICANN, and one is not > guaranteed to pass muster and have their desired name (and associated > namespace management policies) accepted by ICANN -- thus simply referring > to the namespace one level below the root as just a "policy realm" is more > generic and the term can be used to refer to any policy/governance/registry > boundary anywhere in the dns namespace (aka tree). > This is exactly why I make the case in the draft that namespace (including TLDs) is independent from both scope and policy: ...there is no inherent way to determine policy relationships neither by examination of the names themselves, nor by examining the administrative boundaries (i.e., zone cuts) defined in the DNS... In the current specification ([RFC6265]), the semantic requirements were modified to match "public suffixes" because it was recognized that TLDs are not the only domain names with public scope--and that not all TLDs are public suffixes. The notion that all TLDs are inherently public has been challenged by the many and diverse domain names that have been delegated since 2013 as part of the new generic top-level domain (gTLD) program ([NewgTLDs]).... > > 2.3. Domain Name Relationships > > > > In this document two types of domain name relationships are > > identified: ancestry and policy. An ancestral relationship exists > > between two domains if one domain name is an ancestor of the other. > > why introduce yet another term ie "ancestor" ? above, the terminology is > parent / child > Ancestor is a recursive parent. It seemed to me that extending terminology based on the "family tree" theme was intuitive. However, I can define it explicitly if that's not the case. > > A policy relationship exists between two domain names if their > > relationship is such that application policy should treat them as > > equivalent. For example, the two names might be administered by the > > operating organization, or there might business or other > > relationships between the two operating entities. > > clean up above > Could you please be more specific about your concerns and/or supply a wording to update the text? > > In the simplest case, two domain names might be policy-related for > > all applications or purposes. However, it is possible that two > > domains are related only for explicitly defined purposes. > > > > An ancestral relationship between two names can be identified merely > > by comparing the names themselves to determine whether one is a > > substring of the other. However, there is no inherent way to > > determine policy relationships neither by examination of the names > > themselves, nor by examining the administrative boundaries (i.e., > > zone cuts) defined in the DNS. This is the problem being considered > > in this document. > > clean up above > Could you please be more specific about your concerns and/or supply a wording to update the text? > 3. Policy-based Domain Name Relationships > > > > Because policy-based domain name relationships are not inherently > > apparent based on the names themselves or DNS protocol, mechanisms > > outside the DNS namespace and base protocol are necessary to > > advertise and detect those relationships. > > ?? > ?? > In this section we enumerate the different types of ancestral and > > scope relationships upon which policy-based relationships can be > > overlaid. > > > > 3.1. Cross-Scope Policy Relationships > > > > If scope of one domain name is public and another is private, then it > > can be inferred, by the definition of their respective scopes, that > > there exists no policy-based relationship between the two. That is, > > a public domain name cannot be related, for policy purposes, to a > > private domain name. > > > > Note that this doesn't prohibit policy relationships between two > > domain names of the same scope but having (an even number) of scope > > boundaries in between. > > public/private is too coarse-grained > This inferred property does not suggest an equivalence between policy and scope boundaries, but rather that crossing scope boundaries indicates that a policy relationship does not exist, by definition. --001a113f9ae457d92305120a52a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I noticed that the first part of my response was acci= dentally omitted from the message that was actually sent, so I'm rewrit= ing it here.

Casey
On Mon, Mar 23, 2015 at 12:53 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:
>=C2=A0 =C2=A0 As noted in [RFC1034], the term "domain name" i= s used in contexts
>=C2=A0 =C2=A0 outside the DNS.=C2=A0 The scope of this document is limi= ted to domain
>=C2=A0 =C2=A0 names as defined by the DNS.

aside: is there an RFC for "the DNS" that is equivalent to, say, = RFC3377 (which defined the LDAPv3 spec set) ?


RFC 1034/1035?
=C2=A0
>=C2=A0 =C2=A0 ([RFC6265]).=C2=A0 For example, children of the top-level= domain (TLD)
>=C2=A0 =C2=A0 com, are generally registrable by arbitrary entities, whi= ch puts the
>=C2=A0 =C2=A0 com domain name in the public scope.=C2=A0 However, com&#= 39;s children are
>=C2=A0 =C2=A0 typically not used in the same fashion (though certainly = there are
>=C2=A0 =C2=A0 exceptions), which puts them largely in the private scope= .

need more thoroughly defined notion=C2=A0 of public & private because t= here are so many shades of grey in between them -- the diff is actually mor= e which registry controls particular portions of the namespace, its policie= s, and who administers it aka "policy authority {realm,domain,range,sc= ope,..}"

Could you explain what yo= u mean by shades of grey?=C2=A0 If it is grey, then it must not be public.<= br>
See also the NOTE in bullet 5 of section 5.3 in RFC 6265.=
=C2=A0
i.e., declaring this particular scope dimension as simply public or private= is too coarse grained and potentially misleading=C2=A0

=C2=A0 domain registry scope =3D=3D policy realm=C2=A0 =C2=A0 (see [1])

The draft distinguishes between scope and = policy relationships, and there is not an equivalence between the two.
= =C2=A0
>=C2=A0 =C2=A0 The most well-known delineator of public/private scope is= the Public
>=C2=A0 =C2=A0 Suffix List (PSL) [PSL], which is described later in this= document.


It is quite unfortunate that the term "effective TLD" was supplan= ted by "public suffix" -- and even effective TLD is too coarse of= a term for what it effectively represents

<= div>There is a difference between what it *represents* and how it is being = *used*.=C2=A0 The PSL is a list defining suffixes known to be of public sco= pe.=C2=A0 When used (exclusively) as the basis for policy, then it can in f= act be too coarse.
=C2=A0
> 2.2.1.=C2=A0 Public/private Boundaries
>
>=C2=A0 =C2=A0 If we consider the root domain name itself to be public, = then between
>=C2=A0 =C2=A0 the root domain name and any private domain name (below),= there must
>=C2=A0 =C2=A0 exist at least one boundary going from some public parent= to private
>=C2=A0 =C2=A0 child.=C2=A0 The first such boundary encountered upon dow= nward traversal
>=C2=A0 =C2=A0 from the root is the first-level public boundary.=C2=A0 S= ubsequent public-
>=C2=A0 =C2=A0 to-private boundaries are referred to as lower-level publ= ic
>=C2=A0 =C2=A0 boundaries.=C2=A0 For example, because the com domain nam= e is considered
>=C2=A0 =C2=A0 public, if we assume that example.com is private, then the first-
>=C2=A0 =C2=A0 level public boundary is between com and example.com.=C2=A0 If the
>=C2=A0 =C2=A0 p= ublic.example.com domain name is considered public (i.e., children
>=C2=A0 =C2=A0 domain names can be registered by arbitrary third parties= ) and
>=C2=A0 =C2=A0 foo.public.example.com is a private domain name, then a lower-level<= br> >=C2=A0 =C2=A0 public boundary exists between public.example.com and
>=C2=A0 =C2=A0 foo.public.example.com.


having discussion of the fact as one traverses the DNS tree, one will trave= rse policy realm boundaries is useful=C2=A0

using the "public" vs "private" coarse distinction is h= owever, misleading and seriously glosses over the necessary-to-understand n= uance that there can be very fine-grained yet distinct and important differ= ences between the registry policies of one policy realm to another policy r= ealm

Let me reiterate that scope is not= equivalent to policy realm.
=C2=A0

yes, anyone may /attempt/ to register a label directly under the root, henc= e it might seem "public", but doing so is strictly controlled by = a large and complex set of policies administered by ICANN, and one is not g= uaranteed to pass muster and have their desired name (and associated namesp= ace management policies) accepted by ICANN -- thus simply referring to the = namespace one level below the root as just a "policy realm" is mo= re generic and the term can be used to refer to any policy/governance/regis= try boundary anywhere in the dns namespace (aka tree).

This is exactly why I make the case in the draft that names= pace (including TLDs) is independent from both scope and policy:

...there is no inherent way to determine policy relationships neither by examination of the names themselves, nor by examining the administrative boundaries (i.e., zone cuts) defined in the DNS...
   In the current specificati=
on ([RFC6265]), the semantic requirements
   were modified to match "public suffixes" because it was recogn=
ized
   that TLDs are not the only domain names with public scope--and that
   not all TLDs are public suffixes.  The notion that all TLDs are
   inherently public has been challenged by the many and diverse domain
   names that have been delegated since 2013 as part of the new generic
   top-level domain (gTLD) program ([NewgTLDs])....
=C2=A0
> 2.3.=C2=A0 Domain Name Relationships
>
>=C2=A0 =C2=A0 In this document two types of domain name relationships a= re
>=C2=A0 =C2=A0 identified: ancestry and policy.=C2=A0 An ancestral relat= ionship exists
>=C2=A0 =C2=A0 between two domains if one domain name is an ancestor of = the other.

why introduce yet another term ie "ancestor" ?=C2=A0 =C2=A0above,= the terminology is parent / child

Ance= stor is a recursive parent.=C2=A0 It seemed to me that extending terminolog= y based on the "family tree" theme was intuitive.=C2=A0 However, = I can define it explicitly if that's not the case.
=C2=A0=
>=C2=A0 =C2=A0 A policy relationship exists between two domain names if = their
>=C2=A0 =C2=A0 relationship is such that application policy should treat= them as
>=C2=A0 =C2=A0 equivalent.=C2=A0 For example, the two names might be adm= inistered by the
>=C2=A0 =C2=A0 operating organization, or there might business or other<= br> >=C2=A0 =C2=A0 relationships between the two operating entities.

clean up above

Could you please be more= specific about your concerns and/or supply a wording to update the text?=C2=A0
>=C2=A0 =C2=A0 In the simplest case, two domain names might be policy-re= lated for
>=C2=A0 =C2=A0 all applications or purposes.=C2=A0 However, it is possib= le that two
>=C2=A0 =C2=A0 domains are related only for explicitly defined purposes.=
>
>=C2=A0 =C2=A0 An ancestral relationship between two names can be identi= fied merely
>=C2=A0 =C2=A0 by comparing the names themselves to determine whether on= e is a
>=C2=A0 =C2=A0 substring of the other.=C2=A0 However, there is no inhere= nt way to
>=C2=A0 =C2=A0 determine policy relationships neither by examination of = the names
>=C2=A0 =C2=A0 themselves, nor by examining the administrative boundarie= s (i.e.,
>=C2=A0 =C2=A0 zone cuts) defined in the DNS.=C2=A0 This is the problem = being considered
>=C2=A0 =C2=A0 in this document.

clean up above

Could you please be more= specific about your concerns and/or supply a wording to update the text? <= br>
> 3.=C2=A0 Policy-based Domain Name Relationships
>
>=C2=A0 =C2=A0 Because policy-based domain name relationships are not in= herently
>=C2=A0 =C2=A0 apparent based on the names themselves or DNS protocol, m= echanisms
>=C2=A0 =C2=A0 outside the DNS namespace and base protocol are necessary= to
>=C2=A0 =C2=A0 advertise and detect those relationships.

??

??

>=C2=A0 =C2=A0 In this section we enumerate the different types of ances= tral and
>=C2=A0 =C2=A0 scope relationships upon which policy-based relationships= can be
>=C2=A0 =C2=A0 overlaid.
>
> 3.1.=C2=A0 Cross-Scope Policy Relationships
>
>=C2=A0 =C2=A0 If scope of one domain name is public and another is priv= ate, then it
>=C2=A0 =C2=A0 can be inferred, by the definition of their respective sc= opes, that
>=C2=A0 =C2=A0 there exists no policy-based relationship between the two= .=C2=A0 That is,
>=C2=A0 =C2=A0 a public domain name cannot be related, for policy purpos= es, to a
>=C2=A0 =C2=A0 private domain name.
>
>=C2=A0 =C2=A0 Note that this doesn't prohibit policy relationships = between two
>=C2=A0 =C2=A0 domain names of the same scope but having (an even number= ) of scope
>=C2=A0 =C2=A0 boundaries in between.

public/private is too coarse-grained

Th= is inferred property does not suggest an equivalence between policy and sco= pe boundaries, but rather that crossing scope boundaries indicates that a p= olicy relationship does not exist, by definition.
--001a113f9ae457d92305120a52a9-- From nobody Tue Mar 24 13:02:06 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893D1A8BC4 for ; Tue, 24 Mar 2015 13:02:03 -0700 (PDT) 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 l2mud31zpOQi for ; Tue, 24 Mar 2015 13:01:58 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD0E1A8ABE for ; Tue, 24 Mar 2015 13:01:29 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so2826327lbc.0 for ; Tue, 24 Mar 2015 13:01:28 -0700 (PDT) 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=x8iphz6xdbEPYkJrW8brZmeRbobRt/QGbNvECUidtq8=; b=cCLUjF3zj2T8mSx+DC8t0q1FkMn5TLD5WYjyioqsXZ4BR0XKMKk19W3EJ+vn+aSfRK ZtK8xWxiqgWl/vlJAgOkLiONU8MF2TLD5k0BsdDxPElYD2K7z6q04Z4bUe3mhJv1THNQ Edxifwfb1yVFzNULizvfCSnVBTC98VE/OEkLSL3yX1/AjE0YOf2oKKYGMF8YwmjzB2e+ DTX8TNR2Njl6UkTuWr/oaMtbD/7DjZ2bjkcU9yfozy/zd4HSVKvy3vI+LNiUFrhMEGD+ 4/UXAy1NCoextV1hX14InGAPQjdUYBwa4pocmyPYDiP2+DmQW1+/cAzY/l39ymgafRG4 YJ6w== X-Gm-Message-State: ALoCoQmAaMFlDaWHkOqWrb4Z2fW5dyiSpcJgOYAz2jWf/CxGVekXGZKywTWCvMw+CuDWFf1mE1aE X-Received: by 10.152.26.136 with SMTP id l8mr5161848lag.109.1427227288189; Tue, 24 Mar 2015 13:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.126.208 with HTTP; Tue, 24 Mar 2015 13:00:57 -0700 (PDT) In-Reply-To: References: <55104501.3070906@KingsMountain.com> From: Jothan Frakes Date: Tue, 24 Mar 2015 13:00:57 -0700 Message-ID: To: Casey Deccio Content-Type: multipart/alternative; boundary=089e0160c2b886d14d05120e3f67 Archived-At: Cc: =JeffH , "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:02:03 -0000 --089e0160c2b886d14d05120e3f67 Content-Type: text/plain; charset=UTF-8 I won't be able to make it to Texas for the IETF meeting, but wanted to put forth some input. One observation that I have witnessed is that "Public / Private" has some different context, depending upon the reader, and the use and application of these terms. I suspect that these contexts are blurring and confusing things a tad. There is a concept of those that have been delegated directly from IANA/ICANN, and those that jump in at some point within that which are not necessarily 'registries' (some are, some aren't) being Public and Private. I think Casey and John have done a fair job of summarizing some of the contexts of Public/Private within Casey's draft, yet one thing that is possibly blurred between this and the IANA/ICANN direct relationships is the concept of administrative transition. I would not encourage that the PSL definitions of Public/Private sections or comments about entries from within the PSL .dat file be used as any frame of reference other than convenience. The entries as submitted by respective administrators should be used for context of how these administrators wanted cookies to behave. That's essentially it. These are two separate things, regardless of where they are in the file. The cookie realm is different than the SSL Cert realm, is different from the email realm, is different than the _____ realm. Does the PSL get used for other things - absolutely. And each potentially has its own concept of 'Public'/'Private'. As one of the PSL volunteers, I can share the approximate timing of and the origin of 'Public' / 'Private' label in that context as it was introduced in the Mozilla PSL as sections : https://bugzilla.mozilla.org/show_bug.cgi?id=712640 and https://bugzilla.mozilla.org/show_bug.cgi?id=681585 The split really surrounded an accommodation of a section for the new TLDs rather than at the end of the file, to be a continuation of the ICANN/IANA listings, in creation of a process to reasonably update the PSL at the pace that the incredibly efficient contracting and operations teams in ICANN are getting it done. We could have just as easily named the sections "Bert" and "Ernie", or "Wookies" and "Ewoks". It just made more sense that these be read by third parties to latch onto a conceptual context of what was being done. The splitting of entries was literally for managing the ever-growing file, and there was no policy determination made other than to try and make reasonable best efforts to keep those directly assigned by IANA / ICANN (respecting the ICP-3 root) and those not directly assigned (as self-identified by the respective authority or community to the best ability of the volunteers) "organized". The objective has always been to ensure non-discriminatory inclusion of things like Amazon AWS, Centralnic subdomain registries or Github, DYN et al. I'll single out Centralnic as an example of a good actor in the sub-domaining space.. from within the PSL - the bright line example that comes to mind is EU.COM or COM.DE where they operate a registry and assign names underneath these 'As If' they were a TLD. One concern, if I could voice it, would be in inadvertently introducing something that would make it possible for .COM to disallow US.COM or charge additional fees for some special 'blessing' or right to innovate, while in and of itself not inferring a 'blessing' that service through inclusion. The PSL community is agnostic on the inclusion other than to make reasonable efforts to validate the request came from the party administratively responsible for the domain name in question, or the operators of .DE could/would disallow or allow COM.DE by withholding some administrative transfer record in the .DE zone (IF DNS is used for this). Not for any commercial reason, but because of the incredible disruption it would cause to the community of name holders. The core focus of PSL is, from its origin, one of creating a solution to aid in securing cookies from bleeding out to the wrong places. The derivative uses that have evolved since its creation have been amazing and very indicative of a need for solution space, such as search engines, browser 'omnibox' behavior, anti-spam, and the numerous development community. Candidly, (and I realize this additional and important color does not necessarily put these terms into clean buckets) the concept of public/private scope will absolutely change from circumstance of application/use and depend upon that scope - these are different in DNS than in EMAIL than in Cookies and varieties of Web activity. Other examples of derivative uses include UX/UI (form validation being an example, wanting to exclude invalid entries), Security / Log Forensics (need to have a clear indicia of subdomain vs domain ownership breakpoints, to query a whois server, for example). Each will have their own context and scope for 'public' or 'private'. I would encourage that where possible, there can be a scope included in DBOUND efforts which contextually identify the usage, akin to how MX vs A records work in DNS. I'll repeat something that is frequently said within the community of developers who like myself help maintain the PSL, PSL exists only because nothing else did, and it is the least awful solution out there. In the context of our DBOUND efforts, there would be a grateful transition to something that does what it does or better, but it is likely that something that does not, shall not be attractive enough to the base of developers, libraries, and integrators to make the effort to pivot to something else. -Jothan Jothan Frakes Tel: +1.206-355-0230 On Mon, Mar 23, 2015 at 12:58 PM, Casey Deccio wrote: > Thanks for the comments. Those not implicitly addressed by the > public/private scope commentary in the forked thread or otherwise > necessitating additional commentary are addressed below. > > Thanks, > Casey > > > 3.2.1. Public-public Policy Relationships > >> > >> > The connotation of a public domain name in the context of policy is >> > that it should not be used for purposes normally associated with >> > private domain names. For example, it would be unreasonable to >> > expect legitimate mail to come from an email address having the exact >> > suffix of org.au (a domain name currently identified by [PSL] as >> > being public). This is especially true of domain names above the >> > first-level public boundary. >> >> why? could not the administrators of a particular policy realm, even a >> single-label one, cause email (eg theirs) to be sent "from" an address at >> that single-label policy realm? >> > > Again - we're not talking about policy realms. This is a discussion of > public-scoped names, which by definition, have certain distinction, in > terms of their use and constraints, from private names. > > >> also are not single-label domains emerging in real fact? >> > > Note that I explicitly challenge the notion that a single label implies > public (or that public implies single-label, for that matter. > > > 3.2.2. Private-private Policy Relationships >> > >> > There are two classes of potential private-private policy >> > relationships: ancestral and cross-domain (non-ancestral). In >> > neither case can the presence or absence of a policy relationship be >> > confirmed using only the names and scope information. >> >> what scope information? >> > > The fact that they are both private--probably needs a parenthetical to > this effect. > > >> > known as cookies ([RFC6265]). While most often cookies are initially >> > set by HTTP servers, HTTP clients send all cookies in HTTP requests >> > for which the domain name in the URI is within the cookies' scope. >> > The scope of a cookie is defined using a domain name in the "domain" >> > attribute of the cookie. When a cookie's "domain" attribute is >> > specified as a domain name (as opposed to an IP address), the domain >> > name in the URL is considered within scope if it is a descendant of >> > the "domain" attribute. >> >> >> hm need to check 6265 >> >> > This is probably simplistic, and more language from RFC 6265 sections 5.3 > and 5.4 should probably be integrated. > > >> > RFC 2965 [RFC2965] (now obsolete) required that the value of the >> > "domain" field carry at least one embedded dot. This was to prohibit >> > TLDs--which were almost exclusively public--from being associated, by >> > policy, with other domains. Cookies having public scope would enable >> > the association of HTTP requests across different, independently >> > operated domains, which policy association raises concerns of user >> > privacy and security. >> > >> > In the current specification ([RFC6265]), the semantic requirements >> > were modified to match "public suffixes" because it was recognized >> > that TLDs are not the only domain names with public scope--and that >> > not all TLDs are public suffixes. The notion that all TLDs are >> > inherently public has been challenged by the many and diverse domain >> > names that have been delegated since 2013 as part of the new generic >> > top-level domain (gTLD) program ([NewgTLDs]). >> >> the latter is correct, tho am not sure of reason to explain this >> distinction in this way. the latter paragraph illustrates the more >> fine-grained distinctions between policy realms rather than using the >> coarse terms public/private. >> >> > scope != policy domain > > >> > 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 (CA/B >> > Ballot 74 [CA/B-Ballot-74]). >> >> referencing a ballot in a non-open org? why not the BRs ? >> > > If you have a better reference, I'm happy to substitute. The use cases > are more valuable the more specific they are. > > >> > Authorities do not (knowingly) issue certificates for >> > public domain names such as *.org.au. >> >> what is the distinction/implication of the latter name? >> >> > That it is a public name (as defined in the PSL) and is used earlier in > the document as an example of such. I can use another parenthetical to > remind the reader of that. > > >> > The most well-known resource currently available for identifying >> > public domain names is the Public Suffix List (PSL) [PSL]. The PSL >> > is explicitly referenced as an example of an up-to-date public suffix >> > list in [RFC6265]. >> >> well, more or less up-to-date >> >> > The intent of the carefully-worded statement above is not to support or > refute the statement from RFC 6265, but simply to reference it. > > > accurate. Of the 6,823 entries in the PSL at the time of this > >> > writing, all but 50 are used to designate first-level public >> > boundaries; the remainder designate lower-level boundaries. The >> > primary function of the PSL, therefore, is to delineate first-level >> > public boundaries. >> >> uh, but that's "today" -- it will evolve as the DNS namespace evolves >> > > That's speculative, but 1) yes, the statement represents the primary > function of the PSL both currently (i.e., "today") and for the foreseeable > future; and 2) its evolution would be based on the evolution of the *use* > of the DNS namespace. Remember the distinction is about first-level vs. > lower-level boundary identification. > > >> > Matters of policy that can be settled simply by identifying the scope >> > of the names in question are thus addressed by the PSL. However, the >> > question of determining whether a policy-based relationship between >> > intra-scope names (with the possible exception of those of public >> > scope) are unaddressed. >> >> too coarse >> > > Could you please be more specific? > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > > --089e0160c2b886d14d05120e3f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I won't be able to make it to Texas for the IETF meeti= ng, but wanted to put forth some input.

One observation = that I have witnessed is that "Public / Private" has some differe= nt context, depending upon the reader, and the use and application of these= terms.=C2=A0 I suspect that these contexts are blurring and confusing thin= gs a tad.

There is a concept of those that have been delegated direc= tly from IANA/ICANN, and those that jump in at some point within that which= are not necessarily 'registries' (some are, some aren't) being= Public and Private.

I think Casey and John have d= one a fair job of summarizing some of the contexts of Public/Private within= Casey's draft, yet one thing that is possibly blurred between this and= the IANA/ICANN direct relationships is the concept of administrative trans= ition.

I would not encourage that the PSL definiti= ons of Public/Private sections or comments about entries from within the PS= L .dat file be used as any frame of reference other than convenience.=C2=A0= The entries as submitted by respective administrators should be used for c= ontext of how these administrators wanted cookies to behave.=C2=A0 That'= ;s essentially it.=C2=A0 These are two separate things, regardless of where= they are in the file.

The cookie realm is differe= nt than the SSL Cert realm, is different from the email realm, is different= than the _____ realm.

Does the PSL get used for o= ther things - absolutely.=C2=A0 And each potentially has its own concept of= 'Public'/'Private'.

As one o= f the PSL volunteers, I can share the approximate timing of and the origin = of 'Public' / 'Private' label in that context as it was int= roduced in the Mozilla PSL as sections :=C2=A0https://bugzilla.moz= illa.org/show_bug.cgi?id=3D712640 and=C2=A0https://bugzilla.mo= zilla.org/show_bug.cgi?id=3D681585

The split really surrounded a= n accommodation of a section for the new TLDs rather than at the end of the= file, to be a continuation of the ICANN/IANA listings, in creation of a pr= ocess to reasonably update the PSL at the pace that the incredibly efficien= t contracting and operations teams in ICANN are getting it done.=C2=A0
<= br>We could have just as easily named the sections "Bert" and &qu= ot;Ernie", or "Wookies" and "Ewoks".=C2=A0 It just= made more sense that these be read by third parties to latch onto a concep= tual context of what was being done.

The splitting of entries was li= terally for managing the ever-growing file, and there was no policy determi= nation made other than to try and make reasonable best efforts to keep thos= e directly assigned by IANA / ICANN (respecting the ICP-3 root) and those n= ot directly assigned (as self-identified by the respective authority or com= munity to the best ability of the volunteers) "organized". =C2=A0=

The objective has always been to ensure non-discriminat= ory inclusion of things like=C2=A0=C2=A0Amazon AWS, Centralnic subdomain re= gistries or Github, DYN et al.=C2=A0 I'll single out Centralnic as an e= xample of a good actor in the sub-domaining space.. from within the PSL - t= he bright line example that comes to mind is EU.C= OM or COM.DE where they operate a registr= y and assign names underneath these 'As If' they were a TLD. =C2=A0=

One concern, if I could voice it, would be in ina= dvertently introducing something that would make it possible for .COM to di= sallow US.COM or charge add= itional fees for some special 'blessing' or right to innovate, whil= e in and of itself not inferring a 'blessing' that service through = inclusion.=C2=A0 The PSL community is agnostic on the inclusion other than = to make reasonable efforts to validate the request came from the party admi= nistratively responsible for the domain name in question, or the operators = of .DE could/would disallow or allow COM.DE b= y withholding some administrative transfer record in the .DE zone (IF DNS i= s used for this).=C2=A0 Not for any commercial reason, but because of the i= ncredible disruption it would cause to the community of name holders.
=

The core focus of PSL is, from its origin, one of creat= ing a solution to aid in securing cookies from bleeding out to the wrong pl= aces.=C2=A0 The derivative uses that have evolved since its creation have b= een amazing and very indicative of a need for solution space, such as searc= h engines, browser 'omnibox' behavior, anti-spam, and the numerous = development community. =C2=A0

Candidly, (and I reali= ze this additional and important color does not necessarily put these terms= into clean buckets) the concept of public/private scope will absolutely ch= ange from circumstance of application/use and depend upon that scope - thes= e are different in DNS than in EMAIL than in Cookies and varieties of Web a= ctivity.=C2=A0 Other examples of derivative uses include UX/UI (form valida= tion being an example, wanting to exclude invalid entries), Security / Log = Forensics (need to have a clear indicia of subdomain vs domain ownership br= eakpoints, to query a whois server, for example).=C2=A0 Each will have thei= r own context and scope for 'public' or 'private'.

I would encourage that where possible, there can be a scop= e included in DBOUND efforts which contextually identify the usage, akin to= how MX vs A records work in DNS.

I'll repeat = something that is frequently said within the community of developers who li= ke myself help maintain the PSL, PSL exists only because nothing else did, = and it is the least awful solution out there. =C2=A0

In the context of our DBOUND efforts, there would be a grateful transiti= on to something that does what it does or better, but it is likely that som= ething that does not, shall not be attractive enough to the base of develop= ers, libraries, and integrators to make the effort to pivot to something el= se.

-Jothan





Jothan FrakesTel: +1.206-355-0230


On Mon, Mar 23, 2015 at 12:58 PM, Casey Decc= io <casey@deccio.net> wrote:
Thanks for the comments.=C2=A0 Those not impli= citly addressed by the public/private scope commentary in the forked thread= or otherwise necessitating additional commentary are addressed below.
<= br>
Thanks,
Casey

> 3.2.1.=C2=A0 Public-p= ublic Policy Relationships
>
>=C2=A0 =C2=A0 The connotation of a public domain name in the context of= policy is
>=C2=A0 =C2=A0 that it should not be used for purposes normally associat= ed with
>=C2=A0 =C2=A0 private domain names.=C2=A0 For example, it would be unre= asonable to
>=C2=A0 =C2=A0 expect legitimate mail to come from an email address havi= ng the exact
>=C2=A0 =C2=A0 suffix of org.au (a domain name currently identified by [= PSL] as
>=C2=A0 =C2=A0 being public).=C2=A0 This is especially true of domain na= mes above the
>=C2=A0 =C2=A0 first-level public boundary.

why?=C2=A0 could not the administrators of a particular policy realm, even = a single-label one, cause email (eg theirs) to be sent "from" an = address at that single-label policy realm?

<= /span>
Again - we're not talking about policy realms.=C2=A0 This is= a discussion of public-scoped names, which by definition, have certain dis= tinction, in terms of their use and constraints, from private names.

also are not single-label domains emerging in real fact?

Note that I explicitly challenge the notion that a= single label implies public (or that public implies single-label, for that= matter.

> 3.2.2.=C2=A0 Private-private Policy Relationships
>
>=C2=A0 =C2=A0 There are two classes of potential private-private policy=
>=C2=A0 =C2=A0 relationships: ancestral and cross-domain (non-ancestral)= .=C2=A0 In
>=C2=A0 =C2=A0 neither case can the presence or absence of a policy rela= tionship be
>=C2=A0 =C2=A0 confirmed using only the names and scope information.

what scope information?

The fact= that they are both private--probably needs a parenthetical to this effect.=
=C2=A0
>=C2=A0 =C2=A0 known as cookies ([RFC6265]).=C2=A0 While most often cook= ies are initially
>=C2=A0 =C2=A0 set by HTTP servers, HTTP clients send all cookies in HTT= P requests
>=C2=A0 =C2=A0 for which the domain name in the URI is within the cookie= s' scope.
>=C2=A0 =C2=A0 The scope of a cookie is defined using a domain name in t= he "domain"
>=C2=A0 =C2=A0 attribute of the cookie.=C2=A0 When a cookie's "= domain" attribute is
>=C2=A0 =C2=A0 specified as a domain name (as opposed to an IP address),= the domain
>=C2=A0 =C2=A0 name in the URL is considered within scope if it is a des= cendant of
>=C2=A0 =C2=A0 the "domain" attribute.


hm need to check 6265


This is probably simplistic, an= d more language from RFC 6265 sections 5.3 and 5.4 should probably be integ= rated.
=C2=A0
>=C2=A0 =C2=A0 RFC 2965 [RFC2965] (now obsolete) required that the value= of the
>=C2=A0 =C2=A0 "domain" field carry at least one embedded dot.= =C2=A0 This was to prohibit
>=C2=A0 =C2=A0 TLDs--which were almost exclusively public--from being as= sociated, by
>=C2=A0 =C2=A0 policy, with other domains.=C2=A0 Cookies having public s= cope would enable
>=C2=A0 =C2=A0 the association of HTTP requests across different, indepe= ndently
>=C2=A0 =C2=A0 operated domains, which policy association raises concern= s of user
>=C2=A0 =C2=A0 privacy and security.
>
>=C2=A0 =C2=A0 In the current specification ([RFC6265]), the semantic re= quirements
>=C2=A0 =C2=A0 were modified to match "public suffixes" becaus= e it was recognized
>=C2=A0 =C2=A0 that TLDs are not the only domain names with public scope= --and that
>=C2=A0 =C2=A0 not all TLDs are public suffixes.=C2=A0 The notion that a= ll TLDs are
>=C2=A0 =C2=A0 inherently public has been challenged by the many and div= erse domain
>=C2=A0 =C2=A0 names that have been delegated since 2013 as part of the = new generic
>=C2=A0 =C2=A0 top-level domain (gTLD) program ([NewgTLDs]).

the latter is correct, tho am not sure of reason to explain this distinctio= n in this way.=C2=A0 the latter paragraph illustrates the more fine-grained= distinctions between policy realms rather than using the coarse terms publ= ic/private.


scope !=3D policy domain
=C2= =A0
>=C2=A0 =C2=A0 Secure Socket Layer (SSL) certificate authorities typical= ly validate
>=C2=A0 =C2=A0 certificate signing requests by sending a confirmation me= ssage to one
>=C2=A0 =C2=A0 of the WHOIS contacts for the (private scope) domain name= (CA/B
>=C2=A0 =C2=A0 Ballot 74 [CA/B-Ballot-74]).

referencing a ballot in a non-open org?=C2=A0 why not the BRs ?

If you have a better reference, I'm hap= py to substitute.=C2=A0 The use cases are more valuable the more specific t= hey are.
=C2=A0
> Authorities do not (knowingly) issue certificates = for
>=C2=A0 =C2=A0 public domain names such as *.org.au.

what is the distinction/implication of the latter name?


That it is a public name (as de= fined in the PSL) and is used earlier in the document as an example of such= .=C2=A0 I can use another parenthetical to remind the reader of that.
= =C2=A0
>=C2=A0 =C2=A0 The most well-known resource currently available for iden= tifying
>=C2=A0 =C2=A0 public domain names is the Public Suffix List (PSL) [PSL]= .=C2=A0 The PSL
>=C2=A0 =C2=A0 is explicitly referenced as an example of an up-to-date p= ublic suffix
>=C2=A0 =C2=A0 list in [RFC6265].

well, more or less up-to-date


The intent of the carefully-wor= ded statement above is not to support or refute the statement from RFC 6265= , but simply to reference it.

>=C2=A0 =C2=A0 ac= curate.=C2=A0 Of the 6,823 entries in the PSL at the time of this
>=C2=A0 =C2=A0 writing, all but 50 are used to designate first-level pub= lic
>=C2=A0 =C2=A0 boundaries; the remainder designate lower-level boundarie= s.=C2=A0 The
 >=C2=A0 =C2=A0 primary function of the PSL, therefore, is to delineate f= irst-level
>=C2=A0 =C2=A0 public boundaries.

uh, but that's "today" -- it will evolve as the DNS namespace= evolves

That's speculative,= but 1) yes, the statement represents the primary function of the PSL both = currently (i.e., "today") and for the foreseeable future; and 2)= =C2=A0 its evolution would be based on the evolution of the *use* of the DN= S namespace.=C2=A0 Remember the distinction is about first-level vs. lower-= level boundary identification.
=C2=A0
>=C2=A0 =C2=A0 Matters of policy that can be settled simply by identifyi= ng the scope
>=C2=A0 =C2=A0 of the names in question are thus addressed by the PSL.= =C2=A0 However, the
>=C2=A0 =C2=A0 question of determining whether a policy-based relationsh= ip between
>=C2=A0 =C2=A0 intra-scope names (with the possible exception of those o= f public
>=C2=A0 =C2=A0 scope) are unaddressed.

too coarse

Could you please be m= ore specific?

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


--089e0160c2b886d14d05120e3f67--