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

Hey Martin,

While I'm sure that this is interesting to TAG folks, I don't think that cross-posting IETF charter comments to the list is helpful. Could folks please modify CC: lines on responses accordingly?

Also, if you want to get the attention of WHATWG people, the most direct way to do that is on their IRC / list / etc.

Cheers,


> On 3 Dec 2014, at 6:12 pm, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> 
> 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
>> apps-discuss@ietf.org with any comments you may have.
> 
> I suggest to send this also to public-ietf-w3c@w3.org (W3C/IETF coordination list) and to www-tag@w3.org (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
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 3 December 2014 22:47:21 UTC