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

[Casey Deccio <[e-mail]>]

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?