Re: [Dbound] Request to participate in DBOUND discussions

Jothan Frakes <jothan@gmail.com> Fri, 14 February 2014 21:37 UTC

Return-Path: <jothan@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B291A03A9 for <dbound@ietfa.amsl.com>; Fri, 14 Feb 2014 13:37:48 -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 GoPFGNwnZCqf for <dbound@ietfa.amsl.com>; Fri, 14 Feb 2014 13:37:44 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3C1A023F for <dbound@ietf.org>; Fri, 14 Feb 2014 13:37:43 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id oy12so10071838veb.37 for <dbound@ietf.org>; Fri, 14 Feb 2014 13:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=imgXXbBBo95bWIQV0Dwt0I1ia4sS3wL/5EpqOHkWQPM=; b=uIIpwUIMzYOgh9DT8n/bExmNMTAzRRliWUzwij/7HMMdDkgiMwHN5v/MpbSNZOJYXS 5A9eG039DUcF4PmBWyaNzXTd1UEjq7DXC1YsBtMpKQCGSOmKtjorOTUS36dViZrY5UIs EFZQGTYoGttZTFOR3kolQ2XvtPSuTf6XaDPxaNnFH5qR2Jcc7YVtIrvtP6cuLTrCDuzS +3nsvOLRqbEwRiisrCL/l8Io1sSj6bU7+wmn4B740BMKlOUZQk6fw1xK2G3mv4IYQUGL eor4OFSgtELXECb4SLUMee+E91f3iQuf3hDZT9hSyoXJOtm3C47gyXeS5rvvSqTvUmvi 6FZA==
X-Received: by 10.221.37.1 with SMTP id tc1mr2667883vcb.32.1392413861718; Fri, 14 Feb 2014 13:37:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.74.71 with HTTP; Fri, 14 Feb 2014 13:37:01 -0800 (PST)
In-Reply-To: <D34E52E1-9BDA-4EEA-B49F-FDA831B483B6@hopcount.ca>
References: <CADe2gh4RQW0Tjz=Zm6m8Q0tALu=hLy+M5GvTA+zHkFGKWkpmSw@mail.gmail.com> <AE16216C-B5EA-4207-8ECA-15D9902FAB14@NLnetLabs.nl> <9FAC332C-7D62-480A-8046-820C96341CA5@hopcount.ca> <CADe2gh733znmNa56LGcQ08CZ+7dSK68ORrY56B6TDdAogFdLNg@mail.gmail.com> <D34E52E1-9BDA-4EEA-B49F-FDA831B483B6@hopcount.ca>
From: Jothan Frakes <jothan@gmail.com>
Date: Fri, 14 Feb 2014 13:37:01 -0800
Message-ID: <CADe2gh5Q0EmJrdiq0qh87S_gGvVEefHEzBfBZCcHwrC6jm=x5w@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/alternative; boundary="001a11334c389bafda04f2649ddc"
Archived-At: http://mailarchive.ietf.org/arch/msg/dbound/SF2x0Ye_P0dnW-MZ_cQHKrEkCPM
Cc: Olaf Kolkman <olaf@nlnetlabs.nl>, "marc.blanchet@viagenie.ca" <marc.blanchet@viagenie.ca>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [Dbound] Request to participate in DBOUND discussions
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 21:37:48 -0000

Hi Joe-

Due to client obligations making a schedule conflict, I won't be able to
directly attend the upcoming IETF meeting in London to participate in the
BoF.   I will be in Singapore at the upcoming ICANN meeting and wanted to
participate in (or propose if it is not yet in existence) a BoF there.

Is that possible?



> Your wishlist looks like you're assuming a solution that looks a lot like
> a better-managed and better-structured public suffix list.
>
>
​Yeah, I can definitely see that the list looks like that - actually to be
honest, it is that...  Although I went all-out on a starting point to
include many, many things beyond PSL.   ​​Just wanted to get a wishlist
started.  :)

The list is a set of asks or personal requests I have been approached with
over the past 10-12 years related to different elements of domain
boundaries or domain validation.  This has been from LEA, Security, and DNS
providers but also from just general internet tool developers or people
writing simple web-forms or hosting companies.

I don't want us to get stuck to where we can't think big at the time there
is a blank canvas for us to paint, so why not get all the cans of paint
onto the table, and then let the group discussion evolve what we do.  I am
sure some of this would fall away depending upon group wisdom.

I don't want to necessarily prejudice the group's outcome, but rather
identify needs/wants towards a goal of whatever we would potentially draft
being inclusive of as many real world use cases as possible.  I and others
have participated in pre-Idraft dialog or ghostwriting them and seen them
fall into the ether or not get traction.

PSL exists because there really is not anything else.  It formed in a
vacuum to serve an important need.  We might solve some/all/more than these
needs through the dbound group work.

Full disclosure (and selfishly), I'd like to see something out of this
group that is a viable substitute for PSL.  PSL is volunteer-operated and
it is one of those "no good deed goes unpunished" efforts - the
shortcomings are highlighted frequently than the benefits - by the people
it benefits.  I personally have thousands of hours invested in PSL and
participate in it because I immediately recognized how it benefits
developers and the internet community, and operates in the public interest
- if it can keep up.

A decentralized version with authoritative origins would be far better -
getting registries to maintain something like their suffixes for their
zones in something centralized like PSL can take a lot of coordination and
effort in validating the data and the submission.  Similar to DNSSEC there
is no compulsion on authoritative operators to participate, and there is an
educational gap as to what it is (and isn't).  We also have the other side
of the equation in the 'consumers' within the development / application and
other communities who derive use from this resource to consider as well.



> Is the solution space wide enough to consider other options, e.g.
> publication of policy that communicates the same information in the form of
> data in the DNS, published as resource records?
>
>
I sure hope so.  I think DNS may be well suited for this, especially if
there's some means to decentralize things and place authority into the
hands of the appropriate party, such as the registry operator.


> I'm not saying that one is better than the other (or that the right
> solution requires just one approach, versus more than one), but it'd be
> nice to understand the part (if any) different such approaches could play
> as part of a working group discussion rather than as a pre-baked assumption.
>
> [For illustrative purposes only, just to better explain the question
> above, not jumping to implementation assumptions, I mean something like
>
>   (in the root zone)
>   . IN SOA ...
>   . IN PSL whois.iana.org. "http://www.root-servers.org/"
>
>   (in the COM zone)
>   COM. IN SOA ...
>   COM. IN PSL whois.crsnic.net. "http://www.verisigninc.com/"
>
>   (etc)
>
> i.e. RRSets in the DNS at a zone apex that indicates the presence of a
> registry-like administrative boundary, using the scaffolding already
> present in the DNS to do versioning, cryptographic signatures, etc. No
> doubt any real candidate mechanism would be better fleshed out than the
> above, no need to point out the need for extra RDATA, etc, etc.]
>
>
Thanks for the example.  Could be new record type, might be a few.​​  For
example, the boundaries might be different for Cookies than Whois in a
given zone.

In any event, if there was simply a pointer like that, consumers would want
there to be consistency to those resources, so a suggested structure of
file / resources available at the destination of whatever location would be
wise to include in our scope if our work takes us in that direction.

We would the authority chain to be clear, but also want to not prejudice
(nor introduce opportunity to prejudice) sub-domain providers like
Centralnic (EU.COM, UK.COM etc) or other similar providers from being able
to include resources.