Re: [apps-discuss] Proposed charter for DBOUND WG

["Martin J. Dürst" <[e-mail]>]

Hello Murray,

Just a few points after a quick read-through.

On 2014/12/03 01:59, Murray S. Kucherawy wrote:
> Colleagues,
>
> Below is a proposed charter for a working group we're calling DBOUND, which
> is seeking to solve the problem of finding a way to identify
> administrative/organizational boundaries in the domain namespace.  We'd
> like to get some feedback from outside the team of people that's been
> working on it.
>
> For the sake of tracking the feedback, please reply only to
> [e-mail] with any comments you may have.

I suggest to send this also to [e-mail] (W3C/IETF 
coordination list) and to [e-mail] (W3C TAG public list), and to 
get the attention of people from the WHATWG.

> -MSK, APPSAWG co-chair
>
> dbound charter

The charter is extremely long. I suggest trying to shorten it. I'm sure 
it's possible.

> Various Internet protocols and applications require some mechanism for
> determining whether two domain names are related.  A popular example is
> the need to determine whether example.com and foo.example.com, or
> evenexample.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.  For example, the
> right answer is not always "compare the rightmost two labels".
>
> The particular issue is that 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; 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 considered unacceptable.
>
> For the purposes of this work, domain names are approached as identifiers
> used by organizations and services, independent of underlying protocols
> or mechanisms.  Specifically, the work will not propose any changes to
> DNS protocols except the possible creation of new resource record types
> (RRTYPES).  Furthermore, 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.
>
> 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) and the private names (i.e., organizational names)
> below them.  When this list is inaccurate, it exposes a deviation from
> reality that degrades service to some and can be exploited by others.  Being
> the de facto resource, and lacking a more comprehensive, alternative solution
> for relationship identification, the functionality of the PSL has often been
> misused to accomplish means beyond its capabilities.  For example, there
> is no way to confirm the relationship between two domain names, 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.
>
> Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
> current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
> benefit from having this capability.
>
> The DBOUND working group will develop one or more solutions to this family
> of problems.  If possible, a unified solution will be developed.  However,
> the working group may discover that the email, web, equivalence, and

What is 'equivalence' here? The word isn't used elsewhere.


> possibly other problems require independent solutions, in which case the
> working group will follow that path.  The solutions may or may not involve
> changes to the DNS, such as creation of new resource record types; in any
> case, all such changes will be incremental only.

This looks like it conflicts with a previous sentence, namely:
 > Specifically, the work will not propose any changes to
 > DNS protocols except the possible creation of new resource record types
 > (RRTYPES).

If you write things only once, the charter gets shorter, and there are 
less conflicts :-).

> This working group will not seek to amend the consuming protocols themselves
> (i.e., any web or mail standards) without rechartering, and only after
> completion of the base work.  Any such work undertaken in parallel will
> eeed to be done as individual or independent submissions, or in another

'eeed' -> 'need'

Regards,   Martin.

> working group.
>
> Milestones:
> - TBD
>
> Co-chairs:
> - TBD
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>