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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Dec 2014 08:59:55 -0800

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
[email-masked] with any comments you may have.

-MSK, APPSAWG co-chair

dbound charter

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
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 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
working group.

Milestones:
- TBD

Co-chairs:
- TBD

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 03 Dec 2014 16:12:17 +0900

Hello Murray,

Just a few points after a quick read-through.

> [email-masked] with any comments you may have.

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

> dbound charter

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

> the working group may discover that the email, web, equivalence, and

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

This looks like it conflicts with a previous sentence, namely:
 > Specifically, the work will not propose any changes to
 > (RRTYPES).

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Dec 2014 07:20:45 -0800

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

I'll claim to be one of the folk responsible for causing it to be longer
than one might light.  And I believe there's been significant effort to
make the charter as short as possible, while still doing its job.

Some IETF working groups cover topics that are already reasonably
well-understood by the general Internet technical population; this
permits a relatively terse charter.

Others efforts are not so lucky.  The technology might be new or
obscure.  The problem might not be generally recognized yet.  The goal
or expected solution might not be intuitive.

When a planned activity falls into this latter camp, I believe a charter
should explain the topic and tasks well enough to give the 'general
Internet technical population' a clear understanding of problem and
goal.  That is, it needs to contain the precis of a tutorial.

Unfortunately, that takes verbiage.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Cridland <[email-masked]>
Date: Wed, 3 Dec 2014 16:00:15 +0000

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

I agree - much of the charter is, I think, a problem statement. I can never
remember if we "do" problem statements. But I'm not convinced that the
charter cannot be cut considerably if there's a problem statement to refer
to for much of the detail.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Dec 2014 09:46:49 +1100

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 <[email-masked]> wrote:
> 
> Hello Murray,
> 
> I suggest to send this also to [email-masked] (W3C/IETF coordination list) and to [email-masked] (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.
> 
> If you write things only once, the charter gets shorter, and there are less conflicts :-).
> 

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Dec 2014 13:37:56 +0900

Hello Mark,

Just in private:

On 2014/12/04 07:46, Mark Nottingham wrote:
> 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.

Sorry, I didn't intend to do that. I'm not sure why the TAG got cc'ed, I 
think it was because I was trying to verify the address but forgot to 
delete it once I had copied it to the text of the message.

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.

My suggestion was just to get the attention of the WHATWG people, not to 
get that through the TAG. I think that should be clear from what I 
wrote, but maybe it wasn't. Or maybe that's how you interpreted my text, 
and you are just giving advice on how to do it?

Regards,   Martin.