Subject: [dbound] New version of draft-deccio-dbound-organizational-domain-policy

From: Casey Deccio <[email-masked]>
Date: Mon, 4 Apr 2016 08:39:05 -0400

Hi all,

A new version of draft-deccio-dbound-organizational-domain-policy has been
uploaded.

References:
----
Name:        draft-deccio-dbound-organizational-domain-policy
Revision:    02
Title:        Organizational Domains and Use Policies for Domain Names
Document date:    2016-04-04
Group:        Individual Submission
Pages:        23
URL:
https://www.ietf.org/internet-drafts/draft-deccio-dbound-organizational-domain-policy-02.txt
Status:
https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/
Htmlized:
https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-deccio-dbound-organizational-domain-policy-02

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

General Notes about the Approach
----
The mechanism can be thought of as "policy" delegation.  Policy begins at
the TLD.  The _odup sub-domain is used for that, e.g., _odup.com.  Until
the point in which policy is delegated, policy is below the ODUP name at
hand (e.g., _odup.com -- where "com" is referred to as the organizational
domain).  Policies are either delegated either explicitly using "+org"
directives or by "relegation" using "+bound".  The former is like the use
of NS records to delegate namespace in the DNS; the latter says, "there is
an policy delegation boundary".  In either case, the result is that policy
is now handled by a new organizational domain.

The defaults were carefully considered to match existing behavior,
including cookie use, wildcard use, PSL use, etc.  One of the important
points is that child inherits policy from its organizational domain by
default, so every name doesn't need a policy (i.e., it gets it already from
its parent).  But it can have its own policy, if designated.  Or it can
become its own organizational domain, if appropriate, using "+org" or
"+bound".

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

https://github.com/verisign/odup

Please review and comment.  If you have questions, please let me know.

Casey

---

From: Casey Deccio <[email-masked]>
Date: Mon, 4 Apr 2016 13:57:01 -0400

> of the "_odup" TLD.  Instead, policies are published from the TLD and below.

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

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

Regards,
Casey