Re: [dbound] comments on draft-deccio-domain-name-relationships-00

[Casey Deccio <[e-mail]>]

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 <[e-mail]>
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.