Subject: [Dbound] Sketch charter

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 10:29:27 -0800

Hi all,

I put this together based on the dbound draft Jeff made available via
github during the quasi-BoF in Honolulu.  A bit of it is copied from there,
some of it is from what I overheard in that meeting, and some of it I just
made up while on my way to work.

Edit away.

-MSK

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two Domain Name System (DNS) names are related.  A
popular example is the need to determine whether example.com and
foo.example.com are related; though to humans the answer to this may be
obvious, it is difficult to establish this programatically.

The particular issue is that there is structure imposed by users and by the
domain name registration system that is independent of the architecture and
protocol upon which the DNS is built.

In the realm of email, there is a desire to map an arbitrary domain name to
the registered domain name somewhere in the tree above it, in order to
identify a deterministic location where some sort of statement of policy
regarding that domain name can be found.  With respect to the web, there is
a similar practice of identifying domains as related as long as they share
a common ancestor.  However, there is an additional need for the capability
to declare relationships between arbitrary names.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617) and
Sender Policy Framework (SPF; RFC7008), and current work such as DMARC
(draft-kucherawy-dmarc-base), would certainly benefit from having this
capability.

Currently, the only solution in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is maintained
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.  When this list is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.

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, and equivalence
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 consumer 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
need to be done as individual or independent submissions, or in another
working group.

Milestones:
TBD

Co-chairs:
TBD

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 24 Nov 2014 15:11:37 -0500

>need to be done as individual or independent submissions, or in another

I'd delete the SPF reference. SPF certainly could have used this a decade ago, but now, not so much. There was an attempt at including walking up the DNS tree to an admin boundary in some early drafts, but it was abandoned long ago. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 12:31:49 -0800

On Mon, Nov 24, 2014 at 12:11 PM, Scott Kitterman <[email-masked]>
wrote:

> I'd delete the SPF reference. SPF certainly could have used this a decade
> ago, but now, not so much. There was an attempt at including walking up the
> DNS tree to an admin boundary in some early drafts, but it was abandoned
> long ago.
>

Speaking completely hypothetically, could SPF not benefit from this today
if it became available?

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 24 Nov 2014 12:36:28 -0800

> Speaking completely hypothetically, could SPF not benefit from this today

Only if enough people were willing to bear the pain of re-opening the spec
(SPFbis/bis?) yet again to consider doing something with it.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 24 Nov 2014 16:09:49 -0500

> Speaking completely hypothetically, could SPF not benefit from this today

Not in a backwards compatible way.  

If there were to be a future non-backward compatible update to SPF, then yes, 
it would be useful, but I consider that unlikely anytime soon.  It's certainly 
not a significant rationale for doing the dbound work (which I think is good 
work to do for other reasons).

Scott K

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Nov 2014 22:10:13 +0000

I have two nits that I¹ll raise because these details have been what caused
me (an DNS¹r) much pain regarding DBOUND.

On 11/24/14, 13:29, "Murray S. Kucherawy" <[email-masked]
<mailto:[email-masked]> > wrote:

> determining whether two Domain Name System (DNS) names are related.  A popular
> example is the need to determine whether example.com <http://example.com>  and
> foo.example.com <http://foo.example.com>  are related; though to humans the
> answer to this may be obvious, it is difficult to establish this
> programatically.

I would change this to : require some mechanism for determining whether two
identifiers (based on Domain Name System names) are related.

This is a pain-in-the-neck, pedantic comment but unless we can get folks to
think ³identifiers² and not ³domain names² we will continue to get idiots
like myself wondering if you just want the zone cuts.  (You don¹t.)

> protocol upon which the DNS is built.

That is right.  But the wording just doesn¹t seen to get to the bottom of
it.  Perhaps:

Given two identifiers that happen to correspond to DNS domain names, the
temptation has been to seek a solution that emphasizes the nature and design
of the DNS protocol.  This needs to be resisted; instead a solution Is
needed that emphasizes the needs of the applications using the identifiers,
not merely what the DNS can offer.  An example of failing to do this
inappropriate reliance on the Public Suffix List.  The PSL is (take the
definition from below & mention that the PSL means ³yet another registry²
and all the inherent pratfalls (yes, pratfalls) that come with running a
registry, especially one that is a ³third party² to the elements involved.

> Š 

The definition below:

> producer, known as the Public Suffix List.  This list, which is maintained by
> volunteers on a best-effort basis, contains a list of points in the DNS tree
> at which registrations take place.  When this list is inaccurate, it exposes a
> deviation with reality that degrades service to some and can be exploited by
> others.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 14:25:27 -0800

> work to do for other reasons).

OK.  I wasn't really pushing for that; I was just using my imagination and
thought it might be an interesting use case.  I'll drop it from the text.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 14:30:25 -0800

On Mon, Nov 24, 2014 at 2:10 PM, Edward Lewis <[email-masked]>
wrote:

> I would change this to : require some mechanism for determining whether
> two identifiers (based on Domain Name System names) are related.
>

OK.

> This is a pain-in-the-neck, pedantic comment but unless we can get folks
> to think “identifiers” and not “domain names” we will continue to get
> idiots like myself wondering if you just want the zone cuts.  (You don’t.)
>

Uh oh.  I thought that's exactly what we want (or, more precisely, we're
looking for one particular zone cut of interest).  What nuance of the term
"zone cut" am I missing?

> temptation has been to seek a solution that emphasizes the nature and
> design of the DNS protocol.  This needs to be resisted; instead a solution
> Is needed that emphasizes the needs of the applications using the
> identifiers, not merely what the DNS can offer.  An example of failing to
> do this inappropriate reliance on the Public Suffix List.  The PSL is (take
> the definition from below & mention that the PSL means “yet another
> registry” and all the inherent pratfalls (yes, pratfalls) that come with
> running a registry, especially one that is a “third party” to the elements
> involved.
>

Thanks, I'll fold that (or some parts of it) into the text and see what
comes out.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 14:43:32 -0800

Better?  (Ignore the two typos, they're already fixed in my repo copy)

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether example.com
and foo.example.com are related; although to humans the answer to this may be
obvious, it is difficult to establish this programatically since the right
answer is not always "compare the rightmost two labels".

The particular issue is that there is structure imposed by users and by the
domain name registration system that is independent of the architecture and
protocol upon which the DNS is built.  Stated more generally, given two
identifiers that happen to correspond to DNS domain names, the temptation
thus far has been to seek a solution that emphasizes the nature and design of
the DNS protocol.  This needs to be resisted; instead, a solution is needed
that emphasizes the needs of the applications using the identifiers, not
merely what the DNS can offer.

Currently, the only solution in existence is maintained by a web browser
producer, known as the Public Suffix List.  This list, which is kept current
by volunteers on a best-effort basis, contains a list of points in the DNS
tree at which registrations take place.  When this list is inaccurate, it
exposes a deviation with reality that degrades service to some and can be
exploited by others.  It amounts to a third set of semantics imposed upon
the DNS from without, creating unrealistic expectations and eventually
solving the wrong problem.

In terms of specific use cases: Within the realm of email, there is a
desire to map an arbitrary domain name to the registered domain name
somewhere in the tree above it, in order to identify a deterministic
location where some sort of statement of policy regarding that domain
name can be found.  With respect to the web, there is a similar practice
of identifying domains as related as long as they share a common ancestor.
However, there is an additional need for the capability to declare
relationships between arbitrary names.

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, and equivalence 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.

Milestones:
- TBD

Co-chairs:
- TBD

---

From: "John Levine" <[email-masked]>
Date: 24 Nov 2014 23:29:29 -0000

>> two identifiers (based on Domain Name System names) are related.

Not OK.  Really, we're looking at domain names.  If someone, despite all our
advice to the contrary, imagines that we're talking about zone cuts, that's
not our problem.

>looking for one particular zone cut of interest).  What nuance of the term

Zone cuts have no particular connection to authority.  There are
plenty of places with the same authority on both sides of the cut, and
a smaller but still significant number where names in the same zone
are under different authorities, e.g., all of the blogs at
<name>.blogger.com or the subdomains of uk.com.

Also don't forget my note about cross-tree relationships.  I doubt
we'll be able to find a practical way to represent them, but if we
could, it would be very useful.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 15:49:30 -0800

> advice to the contrary, imagines that we're talking about zone cuts, that's

I took Ed's comment to mean that we're really talking about a domain name
which in the DNS sense is just another name, but to humans who think
outside of the DNS, it is more than just another name.

> <name>.blogger.com or the subdomains of uk.com.

So should we use neither term?  The term "authority" also harkens to the
presence of an SOA which, like a zone cut, doesn't necessarily tell you
anything if it's there.

> could, it would be very useful.

Right, I agree.  Does the latest charter text cover it or do you have a
suggested change?

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 24 Nov 2014 15:51:45 -0800

On Mon, Nov 24, 2014 at 2:43 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> somewhere *in the tree above it* [emphasis added], in order to identify a
> deterministic location where some sort of statement of policy regarding
> that domain name can be found.

If we are interested in possible solutions that could include cross-domain
relationships of policy, why constrain the problem statement to
hierarchical relationships?

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Nov 2014 15:57:16 -0800

> hierarchical relationships?

That hasn't been a use case to date, meaning it has not been the impetus
for the work so far.  That's what this paragraph is describing.  I could
add an "Even better would be..." if you like.

---

From: "John R Levine" <[email-masked]>
Date: 24 Nov 2014 19:38:06 -0500

> outside of the DNS, it is more than just another name.

Let's not get too metaphysical here.  The names are in the DNS, we're 
trying to represent some of the external semantics about how the names are 
or aren't related to each other.

> presence of an SOA which, like a zone cut, doesn't necessarily tell you

Good thought.  Let me check my thesaurus ... management?  control?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2014 03:09:36 -0000

>add an "Even better would be..." if you like.

It was in Andrew's original draft.  Your wording is probably fine --
if we can do it, great, but I'm not holding my breath.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Nov 2014 07:08:51 -0800

> or aren't related to each other.

So given the current text, what would you change?

> Good thought.  Let me check my thesaurus ... management?  control?

The word "authority" doesn't actually appear in the current text, so I
guess we just need to keep it that way.

Any other changes we need to discuss?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 25 Nov 2014 10:27:32 -0500

> given two identifiers that happen to correspond to DNS domain names,
given two domain names

> using the identifiers
using the names

> somewhere in the tree above it
somewhere in the tree

> share a common ancestor
share a common ancestor under the same management

(note that google.com and evil-spammer.com share a common ancestor)

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 11:10:21 -0500

> looking for one particular zone cut of interest).  What nuance of the term

A "zone cut" in DNS parlance is the place where NS records are
inserted at the delegation point, and NS records and an SOA record
exist at an apex.  It's literally a _zone_ cut: zones are boundaries
of DNS administrative convenience, and imply nothing about the policy
boundaries.  (SOA stands for "start of authority", and it means
authority in the DNS sense of authoritative server.)

You're right that there's an analogy between zone boundaries and
policy boundaries, which is how I settled on the Start Of Policy
Authority term (SOPA).  The collateral thumbing of nose at certain
misguided legislative proposals was merely a fringe benefit.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 11:11:47 -0500

> if we can do it, great, but I'm not holding my breath.

We can certainly express it; I already showed how.  The reason I
removed it was because people claimed that their existing code all
depended on hierarchical relationships and they weren't going to
change their code, so I took it out so that they'd stop yelling at me.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Tue, 25 Nov 2014 11:24:06 -0500

Comments below:

OLD:

> Stated more generally, given two
> NEW:

Historically, solutions for identifying relationships between domain names
have been based almost exclusively on the DNS namespace and protocol.
While this basis is often sufficient, the fact that it relies on
assumptions stemming from the nature of the DNS makes 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.

> tree at which registrations take place.
>
> NEW:

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 DNS tree 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., registered names) below them.

>   When this list is inaccurate, it
COMMENT: While the above statement is true, this can be said about any
solution--even those produced by this WG.  So I'm not sure this sentence
adds anything useful, and I think it should be struck.

OLD:

>   It amounts to a third set of semantics imposed upon
> COMMENT: This sentence is subjective and is (in my opinion) much
overstating the problem.  See the restatement below.

NEW:

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.

(OPTIONAL: Additionally, there are questions about the scalability, central
management, and third-party management of the PSL as it currently exists.)

> desire to map an arbitrary domain name to the
>
>
OLD:

> registered domain name
> somewhere in the tree above it,
>
> NEW:
organizational domain name (traditionally in the namespace above it),

>  in order to identify a deterministic
> name can be found.
OLD:

> With respect to the web, there is a similar practice
> NEW:
With respect to the Web, there is a similar need to identify relationships
between different domains, currently accomplished by comparing ancestries.

> relationships between arbitrary names.
NEW:
However, there is also desire to reliably identify relationships outside of
the realm and constraints of the DNS namespace tree.

Regards,
Casey

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2014 09:12:33 -0800

The following is based on the original draft of the 'sketch' draft
charter...

> popular example is the need to determine whether example.com
> <http://example.com> and foo.example.com <http://foo.example.com> are
> related; though to humans the answer to this may be obvious, it is

     related; though to humans
     ->
     subject to the same administrative authority.  To humans...

Since this is an example, make it be very specific to a very common and
very obvious case, while avoiding repetition of a key term like related
(since 'related' hasn't been defined yet and could mean many things.)

> difficult to establish this programatically.

I'd suggest changing "it is...programatically" to something like:

   However the DNS does not currently provide the ability to mark these
   sorts of relationships, which makes them impossible to discern with
   simple programming.

> 
> The particular issue is that there is structure imposed by users and by

     is structure -> is [operational / administrative] structure

Since the DNS certainly has structure (hierarchical) it will help to
distinguish what is meant here.  Not sure whether operational or
administrative helps the most.

     users -> organizations

It's a subtle point, but really, DNS admin/ops stuff is better thought
of in terms of groups rather than individuals.

> the domain name registration system that is independent of the
> architecture and protocol upon which the DNS is built.
> 
> In the realm of email, there is a desire to map an arbitrary domain name

Question:  "map"?  Is that really the proper characterization?  Not sure
what to suggest instead, but the term somehow seems odd to me. Perhaps
"connect" or "link" (where the latter invokes a unix-ism.)

     arbitrary domain name -> fully-qualified domain name (FQDN)

> to the registered domain name somewhere in the tree above it, in order

   the registered domain name somewhere in the tree above it,
   ->
   to a portion of the domain name earlier in its hierarchy.  (This is
   sometimes called the "organizational domain".)

> to identify a deterministic location where some sort of statement of
> policy regarding that domain name can be found.  With respect to the

    domain name -> FQDN

> web, there is a similar practice of identifying domains as related as
> long as they share a common ancestor.  However, there is an additional
> need for the capability to declare relationships between arbitrary names.

   arbitrary names
   ->
   arbitrary names, independent of their respective places in the DNS
   hierarchy.

> Previous work such as Author Domain Signing Practices (ADSP; RFC5617)
> and Sender Policy Framework (SPF; RFC7008), and current work such as
> DMARC (draft-kucherawy-dmarc-base), would certainly benefit from having
> this capability.

A blanket statement like this, without explanation, invites challenges,
confusion, and/or flights of pure fantasy.

For example, DMARC contains the organizational domain construct.  SPF
does not.  So I'm not entirely clear how SPF is relevant; I can imagine
all sorts of possibilities, but the reader should not have to guess.

(For reference, if my guess is correct about what is intended with the
SPF reference, it is almost certainly not a viable mechanism, at scale...)

So, it is reasonable to cite previous work that has explicit constructs
that correspond to the work to be done here, although they need to be
referenced explicitly.

For applications which go beyond existing-but-deficient mechanisms, and
create entirely new constructs for the applications, the hypothetical
utility should be offered separately, explicitly and only in very
tentative terms.

> producer, known as the Public Suffix List.  This list, which is

DMARC also invokes the PSL.

> maintained by volunteers on a best-effort basis, contains a list of
> points in the DNS tree at which registrations take place.  When this
> list is inaccurate, it exposes a deviation with reality that degrades

   with -> from

> service to some and can be exploited by others.
> 
> 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, and
> equivalence 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.

The above presumes that the only line of plausible differentiation is
application service.  It should allow the possibility that
differentiation could be structural, such as one that is appropriate
between ancestral relationships versus others. Note that this particular
distinction is common to file systems...

> This working group will not seek to amend the consumer 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 need to be done as individual or independent submissions,
> or in another working group.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 12:16:48 -0500

> administrative helps the most.

Neither helps enough.  "Operational" could easily mean DNS operations,
and "administrative" similarly.  Indeed, the SOA record, zone cuts,
and all that _are_ the administrative boundaries in the DNS.

This is the reason I selected "policy" as the term I used as opposed
to those two.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2014 17:19:25 +0000

(Combining three messages in one reply.)

>Better?  (Ignore the two typos, they're already fixed in my repo copy)

This addresses my concerns.  So far.  No doubt I¹ll have more concerns
later.  But this begins to separate this from being yet another DNS hack
working group (chartering wise).

On 11/24/14, 19:38, "John R Levine" <[email-masked]> wrote:

>>>>Let's not get too metaphysical here.  The names are in the DNS, we¹re
>>>>trying to represent some of the external semantic
>>>>about how the names are or aren't related to each other.

I think we need to.  But I agree not too much.  I¹ve seen a lot of
confusion caused by melting the identifier¹s role and the domain name
system¹s underpinnings.  I think the a major contribution from this effort
will be to define what is needed to establish the relationship of
identifiers, with knowledge of the DNS but without forcing the solution to
be tied to the structure of the DNS.

After reading the charter, I went back to the mail of a week ago and see
this even more clearly.  E.g., we want to not have to post this kind of
message, where we argue over DNS terms and then excuse the tripping over
DNS administration and policy boundaries.

    http://www.ietf.org/mail-archive/web/dbound/current/msg00173.html

There were other messages skirting the point, there¹s no ³smoking gun
message² but it¹s clear that many of us are still blurring the lines of
the problem being either one of applications or one of DNS.

>>given two identifiers that happen to correspond to DNS domain names,

I disagree with this.  This is not about domain names (in the eyes of
someone who¹s spent umpteen years thinking the world revolves around port
53) but about what they represent.  Whether it¹s a host named in an X.509
Subject Alternate Name or the Œauthority¹ in the Java URL class, or the
sending agent of a mail message, make it clear that it is not about the
domain name system.

Perhaps ³identifier² conjures up a wider array of naming systems.  Maybe
that¹s the hang up.  That¹s why I suggested saying ³identifiers based on
domain names² and then for the rest of the charter sticking to identifiers.

If we don¹t do this, we are going to repeat the cycle of stamping out DNS
details (like DNS zone cuts) as new people become engaged in the
discussions.  At this point, those already tuned it will have seen this
discussed, but I know from experience of being a late comer - and seeing
late comers come on board - details like this will return.  At least if it
is in the charter there¹s a higher chance of dealing with this than if it
is buried in the pre-WG archives.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2014 09:22:23 -0800

> This is the reason I selected "policy" as the term I used as opposed

For general discussion in formulating IETF work, the word "policy"
without quite a bit of supporting material is almost never helpful (IMO,
of course) given how vague and often confusing the term is in IETF
discussions.

(I'm not suggesting never using it, but merely never using it without
considerably more clarity and precision.)

The point I intended is that either operational or administrative would
be reasonable; I doubt the distinction is essential at this point of in
the text.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2014 09:29:12 -0800

> be tied to the structure of the DNS.
...
> 53) but about what they represent. 

This is a spectacularly basic point of distinction, for the work being
done here.

It is one thing to revise/augment the DNS and quite another to define an
overlay (identifier) mechanism that happens to use the DNS.

To insist on the abstraction 'identifier' is to insist on an overlay model.

We should get agreement about the nature of the work to be done.

If this is about an overlay identifier mechanism, where is this
described.  We need to understand the identifier model because we can
consider enhancing 'relationships' in it.

If this is about enhancing the DNS itself, then we should say domain
name and not identifier or some other abstraction.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Nov 2014 09:30:12 -0800

Here's where we are right now.  It folds in all suggestions, but that
includes John's last one with which Ed is disagreeing.

I guess we should hear from others on the use of "identifiers" versus
"domain names".  Anyone else care to comment?

Ed or John, care to propose some compromise text?

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two identifiers based on Domain Name System (DNS) names
are related.  A popular example is the need to determine whether example.com
and foo.example.com are subject to the same administrative authority.
To humans, the answer to this may be obvious.  However, the DNS does not
currently provide the ability to mark these sorts of relationships, which
makes them impossible to discern with simple programming.  For example,
the right answer is not always "compare the rightmost two labels".

The particular issue is that there is policy structure imposed by
organizations and by the domain name registration system that is independent
of the architecture and protocol upon which the DNS is built.  Historically,
solutions for identifying relationships between domain names have been based
almost exclusively on the DNS namespace and protocol.  While this basis is
often sufficient, the fact that it relies on assumptions stemming from the
nature of the DNS makes 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.

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 DNS tree 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., registered 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 (traditionally in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that domain name 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 DNS namespace tree.

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

On Tue, Nov 25, 2014 at 9:22 AM, Dave Crocker <[email-masked]> wrote:

> _______________________________________________
> Dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 12:39:05 -0500

> of course) given how vague and often confusing the term is in IETF

This is probably true.  But the point is that the thing we're talking
about is operational policy about the name in the DNS, and _not_
operation of the name in the DNS.  I don't have a better word that
"policy", though I agree with you that it has problematic baggage.  

> be reasonable

The point I'm trying to make, however, is that those words are both
going to cause confusion, because people who come at this with a DNS
background will immediately associate each of them with the associated
activity of the domain itself (i.e. administration or operation of the
DNS bits of that name).  That's _precisely_ the thing we're not
talking about.  When I was first trying out these ideas, I used both
"operational" and "administrative" in early discussions, and fell into
this very problem with my interlocutors; so I'm not worrying about
something theoretical.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 12:46:06 -0500

On Tue, Nov 25, 2014 at 05:19:25PM +0000, Edward Lewis wrote:

> Subject Alternate Name or the authority¹ in the Java URL class, or the

It is not about the DNS, correct, but it is about domain names.  That
is, the work is not intended to apply to other kinds of identifiers
such as complete email addresses, NetBIOS names, mDNS names, and so on.

I think what you need is something like this:

    For the purposes of this work, domain names are approached as
    identifiers used in other services, and not as DNS names in
    themselves.  The working group is not chartered to do any work on
    management of the DNS itself.  The structure of the DNS and the
    administrative boundaries in the DNS are entirely out of scope for
    the working group.

Then we can use "domain names"; I think John is right that we are in
fact working on identifiers that are always domain names, and that it
is therefore wrong not to call them by that name.  But you're quite
right that we need to call out quite clearly that fact, or we'll spend
half our time explaining why zone cuts don't help.  (No matter what we
do, we'll probably have to do that explanation several times anyway.)

> domain names² and then for the rest of the charter sticking to identifiers.

"Identifiers" is clearly too broad, IMO.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Tue, 25 Nov 2014 13:18:39 -0500

On Tue, Nov 25, 2014 at 12:46 PM, Andrew Sullivan <[email-masked]>
wrote:

>
> It is not about the DNS, correct, but it is about domain names.

Agree.

> The structure of the DNS and the

Here I disagree.  What good would it do us to move this out of scope?
There is a difference between relying exclusively on the DNS structure and
administrative boundaries for solving the problem and not being constrained
by them for the purposes of solving the problem.

> "Identifiers" is clearly too broad, IMO.

Agree.

Casey

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 13:21:13 -0500

> Here I disagree.  What good would it do us to move this out of scope?

There already is a WG that has that in scope, and I would expect the
IESG to be reluctant to charter two WGs with the same
responsibilities.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2014 18:48:29 +0000

>consider enhancing 'relationships' in it.

My intent is not to create an overlay identifier mechanism, but rather...

>name and not identifier or some other abstraction.

...Avoid the notion that we are enhancing the DNS.

That’s why I’ve used “identifiers based on domain names”.

I can’t call them identifiers syntactically the same as domain names
because I doubt (correct me if I am wrong) that the X.509 Subject
Alternate Name field would encode “www.example.com” as characters in ASN.1
and not in the DNS wire format (like - 3www-7example3com0).

I realize that to most people “host.example.com” is what is sent in dig to
get an address or in ssh to login to a host.  But there is a recognized
difference between 127.0.0.1 and 1.0.0.127.in-addr.arpa.  In dig and ssh,
the two would be treated differently (yes, there is dig -x).

My goal is not to dredge up an identifier system.  My goal is bury the
notion that we are enhancing the DNS.  If there’s another way to do this,
I’m open to suggestion.  (I mean, another apart from mentioning in the
intro "identifiers based on domain names.”

The fact is that we have a defacto identifier overlay abstraction in place
- ever since URLs included in the “printed” form of DNS.  No need to
define it, just dance around it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Nov 2014 10:55:25 -0800

> define it, just dance around it.

Does Andrew's proposed paragraph deal with this concern?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2014 18:56:46 +0000

>Ed or John, care to propose some compromise text?

I’ve done enough list damage for this week.  I’ll wait until we get more
opinions. ;)

It’s true that the work “identifiers" is too broad given the application
contexts being considered.  While “identifiers based on domain names” is
the most accurate I can think of, I can see why it isn’t “just right”

But this is about domain names either for reasons I put into a reply to
Dave Crocker.  The URL doesn’t have what is DNS-wise a domain name as it
appears in the DNS system (in DNS parlance it’s zone file form vs. on the
wire).  The operations done in DNS code on domain names don’t transfer to
operations on zone file forms of names.  I know – I’ve code in the area.
E.g., sorting names (as is done in DNSSEC) has to be done in wire format
and not in zone file form.

I’m getting too esoteric.  That’s why I need to stop and hear other
opinions.  I’ve been viewing the world through port 53 way too long.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2014 19:02:41 +0000

Yeah, I’m more in line with Andrew’s tack than Casey’s.

Here I go again….I’m came to this group thinking this might be about the
DNS.  I came from the perspective that it was about zone cuts (evidenced
in my comments on Casey’s pre-IETF91 problem statement).  After the
discussion during IETF 91 I see the problem as entirely external to the
DNS as a system.  It’s about how domain names are manipulated by
applications.  Particularly manipulation of domain names - not general
identifiers.  Given that I agree with Andrew’s paragraph and disagree with
Casey’s disagreement.

The paragraph being:

---

From: Casey Deccio <[email-masked]>
Date: Tue, 25 Nov 2014 15:24:27 -0500

> IESG to be reluctant to charter two WGs with the same

Maybe I'm reading the intent of your above statement incorrectly.  But let
me clarify what I mean.

I am saying that if, as part of developing the solutions to the problems
herein outlined, we deliberately deny any notion of namespace hierarchy
(i.e., because "structure" of the DNS is outside the scope of the working
group) then we are limiting our resources to come up with a viable,
effective, solution, all things considered.  I am not saying that we must
*only* use the DNS structure, that we *must* use the DNS structure at all,
or that somehow changing the DNS structure should be within scope.  But
explicitly moving it out of scope makes things unnecessarily complicated,
particularly because despite all the abstract terminology, the identifiers
we are talking about are, in fact, DNS domain names.

Casey

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2014 12:29:57 -0800

>     administrative boundaries in the DNS are entirely out of scope for

I believe I'm starting to understand what is intended.  I still think
that it's an extremely important point for us to share clarity about,
where 'us' needs to be very broad-based.  So the charter needs to
explain the issue thoroughly enough to make it likely that non-savants
will understand it.

Alas I think that Andrew's text, above, is still far too cryptic, IMO.

(BTW, I take the point about 'domain name' as distinct from "DNS" and
suggest that reference to the DNS be limited to very specific
implementation details.)

With an attempt to avoid rambling and verbosity but the expectation that
neither goal has been achieved, please consider the following discourse
rather than proposed text:

   Domain Names offer a namespace that is hierarchical, but otherwise
unstructured.  Besides the relationships of parent, child and sibling,
the nodes in a domain names do not have structural attributes, such as
indicating that one name is 'related' to another according to some set
of policies or procedures.

   Examples of such relationships include authority boundaries within
the hierarchy and across the hierarchy.  For the former, a 'parent'
domain name is sometimes classed as the organizational domain, to
indicate that the parent domain is at the top of a hiearchy defines a
transition from one "outside" administrative authority to another that
is "inside" the organization. Hence there would need to be a way to
indicate that example.comis the organizational domain for www.example.com.

   Similarly two domain names that might share no part of the domain
name hierarchy other than the domain name root might be subject to the
same administrative authority.  Example.com and example.net could be
controlled by the same organization.

   The requirement to indicate specific relationships between two domain
names depends upon the type of application service using (or asserting)
that relationship.  While the units of concern are still domain names,
they are domain names used within application-specific contexts.

   The working group will define one or more mechanisms to permit
indication and discovery of relationships between domain names,
including indication of the application use(s) of each type of
relationship that is defined.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2014 15:30:22 -0500

On Tue, Nov 25, 2014 at 03:24:27PM -0500, Casey Deccio wrote:

> group) 

I think you're reading more in what I said than what I intended, so
that suggests the text isn't clear.

My point is that the WG ought to be constrained from developing
anything about DNS operations _themselves_, because we already have a
WG to do that.  We're talking about how applications use identifiers
that come from the DNS, and not how the DNS uses things in the DNS.
Does that make clearer what I'm trying to say?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 25 Nov 2014 15:32:53 -0500

> sending agent of a mail message, make it clear that it is not about the

Unless you're proposing to describe relations among arbitrary strings that 
can't be looked up in the DNS, it's most definitely about domain names.

I sympathize with your concern that some people are unable to see the DNS 
other than as zone cuts and RRs, but unless I totally misunderstand what 
we're doing, the identifiers we're talking about are in fact names in the 
DNS.

Regards,

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 25 Nov 2014 12:55:12 -0800

On Tue, Nov 25, 2014 at 11:02 AM, Edward Lewis <[email-masked]>
wrote:

> the problem [is] entirely external to the DNS as a system.
>
It’s about how domain names are manipulated by
> identifiers

Bingo! "Manipulated" and "considered associated with one another" - now if
we could come up with appropriate language to specify this in the charter.

--Kurt

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 25 Nov 2014 16:36:55 -0500

Maybe another way to make the distinction we're talking about: DNS *namespace* but not DNS *protocol*?

The association between names in DNS protocol is limited to namespace hierarchy (with and without zone cuts, which also have protocol significance) and the semantics of specific RRtypes. We may be looking to express and manipulate other kinds of association among names in the DNS namespace for manipulation by, and to the benefit of, applications.

Does this help?

On Nov 25, 2014, at 3:55 PM, Kurt Andersen <[email-masked]> wrote:

> On Tue, Nov 25, 2014 at 11:02 AM, Edward Lewis <[email-masked]> wrote:
> Bingo! "Manipulated" and "considered associated with one another" - now if we could come up with appropriate language to specify this in the charter.
> 
> --Kurt
>

---

From: Casey Deccio <[email-masked]>
Date: Tue, 25 Nov 2014 16:50:14 -0500

> *namespace* but not DNS *protocol*?
Yes!

> The association between names in DNS protocol is limited to namespace
> hierarchy (with and without zone cuts, which also have protocol
> significance) and the semantics of specific RRtypes. We may be looking to
> express and manipulate other kinds of association among names in the DNS
> namespace for manipulation by, and to the benefit of, applications.
>
>
Sounds about right to me.

Casey

---

From: Jothan Frakes <[email-masked]>
Date: Tue, 25 Nov 2014 15:39:56 -0800

Brilliant suggestion Suzanne.

Jothan Frakes
Tel: +1.206-355-0230

---

From: "John Levine" <[email-masked]>
Date: 26 Nov 2014 00:47:09 -0000

>Maybe another way to make the distinction we're talking about: DNS *namespace* but not DNS *protocol*?

Sounds reasonable to me.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Nov 2014 17:01:43 -0800

Rather than repeatedly posting the whole thing here, I'm just going to keep
updating this as people make suggestions until you all tell me to stop and
circulate it for approval.  The first place it will go once it's stable
here is apps-discuss, and then to the IESG.

https://github.com/mskucherawy/docs/blob/master/charter-dbound

You can see individual edits and all that through the github UI.

So how's it look now?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 25 Nov 2014 20:26:49 -0500

> So how's it look now?

I'm OK with this version.  Tnx.

Regards,

---

From: Casey Deccio <[email-masked]>
Date: Tue, 25 Nov 2014 22:30:28 -0500

On Tue, Nov 25, 2014 at 8:01 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> Rather than repeatedly posting the whole thing here, I'm just going to
> keep updating this as people make suggestions until you all tell me to stop
> and circulate it for approval.  The first place it will go once it's stable
Looks good!

I recommended in my earlier comments (and still recommend) that the
following sentence be removed, on the basis that it can be said about any
solution--even those produced by the proposed working group:

"When this list is inaccurate, it exposes a deviation from reality that
degrades service to some and can be exploited by others."

(The recommendation was probably lost in the noise; I didn't see any
comments opposing it.)

Other than that proposed edit, I think it is in good shape.

Cheers,
Casey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Nov 2014 21:37:26 -0800

Hi Casey,

> degrades service to some and can be exploited by others."

I did see that comment but I left the sentence in.  In the context in which
it appears, I thought it added useful emphasis to the concern and impetus
for coming up with something better than a table maintained on a
best-effort basis.

> (The recommendation was probably lost in the noise; I didn't see any

I didn't see anyone supporting it either... ;-)

I'm happy to go with consensus in the end, but I wanted to explain why I
left it in.

Ed, what say you?  Others?

-MSK

---

From: Casey Deccio <[email-masked]>
Date: Wed, 26 Nov 2014 00:47:01 -0500

On Wed, Nov 26, 2014 at 12:37 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> I did see that comment but I left the sentence in.  In the context in
> which it appears, I thought it added useful emphasis to the concern and
> impetus for coming up with something better than a table maintained on a
> best-effort basis.
>
> ...

Fair enough.  While I realize the intent was to identify shortcomings of
the existing solution, I felt this particular observation was unfairly
applied (only) to the PSL when it is in fact a more general shortcoming.
The softer sentence that alluded to, but didn't explicitly call out
problems such as this was: "Additionally, there are questions about the
scalability, central management, and third-party management of the PSL as
it currently exists."

That being said, this isn't a showstopper as far as I'm concerned, and
consensus opinion is good :)

Casey

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Nov 2014 08:25:44 -0800

> determining whether two Domain Name System (DNS) names are related. A

I thought there was agreement to say "Domain Names" and not "DNS", in
order to distinguish the administration of namespace assignments from
the operational query service that uses them.

> foo.example.com are subject to the same administrative authority. To

Might as well include the example of 'seemingly unrelated' names here,
as well.  SO:

   foo.example.com are subject
   ->
   foo.example.com, or even example.net, are subject

> humans, the answer to this may be obvious. However, the DNS does not

the sentence is a bit awkward. to simplify:

   relationships, which...programming
   ->
   relationships.  This makes it impossible to discern relationships
   algorithmically.

> The particular issue is that there is policy structure imposed by

"policy structure"?  That has a nice sound to it, but I doubt it will
have obvious and consistent meaning to a broad base of readers.

Perhaps:

   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.

> almost exclusively on the DNS namespace and protocol. While this basis is

'almost exclusively on...'?  This sentence (and section of text) is far
too cryptic.  It needs an explicit reference.

> nature of the DNS makes such solutions unreliable and unnecessarily

I thought the most popular mechanism was a manually-maintained table.
That doesn't really have any 'assumptions' to it.  And I don't know what
other mechanisms there are, nor what their assumptions are.

> For the purposes of this work, domain names are approached as identifiers
> used in other services, and not as DNS names in themselves. The working group

I believe this statement is simply incorrect.  The 'identifiers' are
domain names.  They are used as domain names.

The work intended here can be characterized as adding a layer of
relational 'structure' to domain names, without changing any of the
underlying domain name administration (or any of the associated
operational service.)

> is not chartered to do any work on management of the DNS itself; the work
> here is entirely focused on the DNS namespace, and not the DNS protocol. The
> structure of the DNS and the administrative boundaries in the DNS are
> thus entirely out of scope for the working group.

While it's good that the term org domain is being used, it needs more
definition, since some readers of the charter won't know what it means.
That's why I gave a working definition in the text a posted.

Also, the addition of "traditionally" here is interesting.  Is there a
view that an organizational domain is not always somewhere directly up
the branch?  I don't recall hearing this before.

> of policy regarding that domain name can be found. With respect to the

'that domain name' is unfortunately ambiguous.  The sentence contains
two references to domain name.  In fact, I'm not sure which is meant to
be referenced here.

> and constraints of the DNS namespace tree.

   DNS -> Domain Name

> case, all such changes will be incremental only.

Hmmm.  "changes to the DNS"?  Is that really meant, given the 'domain
name'/DNS distinction?

---

From: Casey Deccio <[email-masked]>
Date: Wed, 26 Nov 2014 12:04:23 -0500

> too cryptic.  It needs an explicit reference.

"relied primarily on..." is probably better text for that, especially since
(as you point out below), the usage is ubiquitous but not exclusive.

> I thought the most popular mechanism was a manually-maintained table.

The PSL still relies on DNS namespace.  It identifies the (so-called)
public/private boundaries in the namespace, and the applications use
namespace in conjunction with that delineation to determine policy.

> other mechanisms there are, nor what their assumptions are.
The illustration of the assumptions (and the one you commented on above) is
provided in the following sentence, which you quote below.

> domain names.  They are used as domain names.
Maybe you want to say:

"... used in other services, independent of the DNS protocol and
infrastructure."

> That's why I gave a working definition in the text a posted.

Note that the rest of the sentence provides some context here (i.e.,
referring to organizational policy).  However, if that is still
insufficient, here's a possible rewrite:

...desire to link an arbitrary fully-qualified domain name (FQDN) to its
organizational domain name (traditionally in the namespace above it), from
which its policy is inherited and may be retrieved from a deterministic
location.

> the branch?  I don't recall hearing this before.

I think this is in reference to the fact that there is some desire/demand
to signal/identify cross-domain relationships (i.e., outside the DNS
namespace hierarchy), which might apply to email or some other application.

> two references to domain name.  In fact, I'm not sure which is meant to

With the (possible) rewrite above, this is helped.  Alternatively, throwing
in "organizational" before domain name helps clarify.

Casey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Nov 2014 10:33:40 -0800

> the operational query service that uses them.

Everywhere else in the charter, it does.  Here it's a mixture of "domain
names" and a first expansion of the acronym "DNS".  Do they not say the
same thing?

> too cryptic.  It needs an explicit reference.

There are plenty of examples like SPF and DKIM/ADSP, and now DMARC, that
try to do this.  In fact I can't think of an example of a domain name
relationship scheme that is a valid counter example.  Anyone have a
suggestion?  DNAME perhaps?

> other mechanisms there are, nor what their assumptions are.

We're not talking about the PSL here (yet), but rather previous attempts to
do the same thing using stuff like DNS tree-walks that we've ultimately
rejected (e.g., during the SSP discussions).

> underlying domain name administration (or any of the associated

This was Andrew's suggested text, and I believe he meant only to make it
clear we're not changing DNS protocol or infrastructure.

> That's why I gave a working definition in the text a posted.

I changed it to "registered" instead of "organizational" since we're really
talking about a name that appears in a domain name registry, and I'd rather
not import a definition from DMARC if it can be avoided.

> the branch?  I don't recall hearing this before.

That's in reference to John's (or Kurt's?) point that google.com might want
to express a policy that also covers youtube.com without having to put a
policy record in both places.

> > and constraints of the DNS namespace tree.

Removed "DNS" instead.

> family

I think this makes sense in the context of the rest of the sentence.  We're
only allowed to make incremental changes to the DNS, which as far as I can
imagine could only mean a new RRtype.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 26 Nov 2014 13:39:48 -0800

> I didn't see anyone supporting it either... ;-)

I'm in favor of the statement as a justification for the DBOUND work,
although maybe generalizing it to apply to the "overlay" that we are
working on (or any other), rather than the PSL exclusively would be
reasonable.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Nov 2014 16:31:11 -0800

On 11/26/2014 10:33 AM, Murray S. Kucherawy wrote:
> On Wed, Nov 26, 2014 at 8:25 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Nearly everybody -- possibly even including some DNS savants --
considers the naming scheme and the query service as a single entity.
Wikipedia, for example, introduces DNS as "a hierarchical distributed
naming system..."  I take the presence of "distributed" as referring to
the operational query mechanism.  As a namespace abstraction, domain
names are not 'distributed, though of course they very much are in terms
of the query service.  I think even the original RFCs are a bit casual
about the distinction.

As an exercise, randomly ask folk what they think "DNS" refers to.

Again, I'm working from Andrew's suggestion to decouple namespace from
query service operation.  (Which I think is a good idea.)  So the
charter has the challenge of helping readers avoid a common conflation.

> suggestion?  DNAME perhaps?

My suggestion is to make the nature of each example explicit.  If the
reader is not already expert in SPF or the rest, this will then give
them a specific tag for knowing what to go read about, within texts
about SPF, or the like.

> We're not talking about the PSL here (yet), but rather previous attempts
> to do the same thing using stuff like DNS tree-walks that we've
> ultimately rejected (e.g., during the SSP discussions).

So, part of my confusion -- and possibly confusion of the text -- is
between what has actually been used -- however poorly, versus what has
merely been considered.

> clear we're not changing DNS protocol or infrastructure.

If "not as DNS names in themselves" is supposed to mean "these are
domain names, but they are not being considered in terms of the query
service implementation", then -- as earlier -- I think the goal is fine.
 The problem is the wording.  It requires the reader to understand a
nuance of distinction that, I believe, is not commonly considered.

Perhaps:

   For the purposes of this work, domain names are approached
identifiers used by organizations and services, independent of any
underlying protocols or mechanisms.  Specifically, the work will not
propose any changes to DNS protocols.

> I changed it to "registered" instead of "organizational" since we're
> really talking about a name that appears in a domain name registry, and
> I'd rather not import a definition from DMARC if it can be avoided.

The latest text:

  "desire to link an arbitrary fully-qualified domain name (FQDN) to the
   registered domain name (traditionally in the namespace above it),"

is now confusing.

'Registered' has a different and far broader meaning.  Except in very
unusual scenarios, all domain names -- and all parts of domain names --
are registered.  That's how they get assigned.

My original suggestion offered a self-contained definition of org
domain, so that no reference to dmarc would be needed.  And it defined
it in terms that described what is functionally salient, to distinguish
the org domain.

> That's in reference to John's (or Kurt's?) point that google.com
> <http://google.com> might want to express a policy that also covers
> youtube.com <http://youtube.com> without having to put a policy record
> in both places.

See above.

d/

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Nov 2014 14:33:54 +0000

>Ed, what say you?  Others?

Meta-comment.

The comment by John Levine to not get too metaphysical comes back to
haunt.  Reading the traffic, a lot of it has given over to the split of
‘namespace’ from ‘query system’ - to use one divide.  I think this is
important to cover but this shouldn’t be the stumbling block we should
trip over.  DBound ought to be about how applications treat the names or
identifiers.  The discussion is going over territory that I am sensitive
too, and is what I was trying to address.

An unoriginal comment.  (Kind of a remake of a Hollywood classic into a
3-D animated full length feature.)

Perhaps explicitly stating that this is about how applications rely (in
the sense of being relying parties) on domain names, or the way in which
applications manipulate domain names is needed.  My distaste for
mentioning domain names has ebbed because this is not the issue the group
needs to spend much energy on - it should be about the applications’
actions.

Suggestion to simplify the charter.

For the sake of the charter, I would rather de-emphasize the Public Suffix
List save to perhaps to produce a document describing it (as it is) and
with some analysis of why it is not a general purpose solution or model
for a general solution.  So I don’t think it is appropriate include the
comment "When this list is inaccurate, it exposes” in the charter per se.
In other words, no need to bash work that someone else volunteered to do
under their own initiative.

A vacuous promise.

I’ll re-read the charter suggestion early next week as I’m waiting for the
parade to start on TV now. ;)  (US Thanksgiving.)  In the mean time, there
may be more bright ideas posted.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Nov 2014 08:15:01 -0800

> under their own initiative.

There is a small set of prior work, relevant to the proposed work.  A
charter should make 'useful' reference to that work, in order to
establish a context for the proposed work.

IMO, 'useful' means it should cite the prior work and give some sense of
what it is and how it has not been sufficient or how it points to
needing the current work.  This certainly must not represent bashing,
but needs to motivate the current work.  It needs to give enough
reference so that a motivated reader knows where to go for more
information and what to look for.

Ultimately a reader should be able to know why the proposed work is
worth the considerable cost it will incur.  (Typical IETF standards cost
the community considerably more than US$ 1M and typically a significant
multiple.)  Knowing 'why' is different from knowing 'what' the proposed
work is.

Setting the context not only justifies the proposed work; it constrains
it, by making clear the nature of the need, in a community sense.  It
can help limit "here's a nifty feature I like" in favor of "here's an
essential feature the community needs."

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Nov 2014 15:11:42 -0500

> So how's it look now?

I think it's in good shape, and I'd like to suggest that we've been
staring at it long enough that small differences may loom large to us
and be irrelevant to others.  So I suggest we put it out for comment
either by relevant ADs (I think this is apps and sec, though I'm
prepared to be convinced of ops), or by appsawg and saag, or both.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Naoki Kambe <[email-masked]>
Date: Fri, 28 Nov 2014 10:29:18 +0900 (JST)

Hi,

I have a couple of general questions about the draft charter.

> case, all such changes will be incremental only.

What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?

What is the scope of this WG?  For example, is an interoperability
test using the solutions between a web server and a web browser
included in its scope?

Regards,
Naoki Kambe

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 Nov 2014 23:06:04 -0800

> What does DBOUND stand for?  Dns BOUNDaries?  Domain name BOUNDaries?

Could be either, I imagine.

> test using the solutions between a web server and a web browser

We could include such a thing if people think it might be useful, but I
can't imagine it being a requirement.

-MSK

---

From: Naoki Kambe <[email-masked]>
Date: Fri, 28 Nov 2014 18:42:58 +0900 (JST)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 Nov 2014 23:06:04 -0800
> Could be either, I imagine.

As other proposal, "Domain administrative namespace BOUNDaries"?

> can't imagine it being a requirement.

I personally think someone should validate that the new solutions are
workable.  Whether or not the working group does.

Regards,
Naoki Kambe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 Nov 2014 14:03:46 +0000

>As other proposal, "Domain administrative namespace BOUNDaries"?

Historically the names of Working Groups are not reliable indicators of
the work being done.  I.e., what DBOUND stands for is unimportant at this
stage, defining the WG’s scope is.  Later we can make DBOUND mean
something - or not.

What I mean to express - don’t let the name confine you to what should be
done.

>workable.  Whether or not the working group does.

Again historically the IETF does not get (very) involved in developing
test or validation suites.  I’m not saying this is a good thing or not,
just ‘historically.’

The IETF is more of “the idea person” leaving the realities of getting
things to work to the operators.  ;) Outside of the IETF there are people
that stand up test or visualization tools for protocols.  It would be good
to have testable descriptions of the solutions in the RFCs, but sometimes
that is not achieved.

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2014 16:40:20 -0000

>Could be either, I imagine.

Based on experience, I thought it was Doomed BOUNDaries

>> test using the solutions between a web server and a web browser

I don't ever recall a WG having interop tests in its scope.  There are
certainly groups such as WEIRDS and DKIM that have done interop tests
as a useful side activity.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Nov 2014 08:46:56 -0800

> as a useful side activity.

To expand on this a bit:

     The formal requirements for Proposed Standard do not include
demonstrating implementation or testing experience.  Very rarely, the
working group or the IESG do impose such requirements, as the working
group effort develops.  However I believe they have never been explicit
in a working group charter.

     More important than the formalities is whether work has sufficient
risk and sufficient potential benefit to motivate the community to do
interoperability testing prior to seeking Proposed.

     The upside of the testing is, of course, experience and therefore
presumed specification maturity. The downside is raising the bar for
Proposed too high.  It's a tradeoff best left to the specific working
group situation and, IMO, best left to later stages of wg process.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 28 Nov 2014 23:54:33 -0800

I've taken another run at addressing your concerns and Ed's, but I confess
I'm now going cross-eyed trying to understand what still needs to change.
The feedback is a little too abstract and thus I don't know what parts
still need attention and in what ways.

If you or anyone still thinks this version isn't right, please reply with
some OLD/NEW-style specific edits for me to make.  Otherwise I'm inclined
to agree with Andrew and circulate it to apps-discuss and perhaps saag and
dnsop soon.

One specific comment:

> it in terms that described what is functionally salient, to distinguish

Was there specific text?  I couldn't find this suggestion upthread anywhere.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Nov 2014 07:29:27 -0800

On 11/28/2014 11:54 PM, Murray S. Kucherawy wrote:
> I've taken another run at addressing your concerns and Ed's, but I
> confess I'm now going cross-eyed trying to understand what still needs
> to change.  The feedback is a little too abstract and thus I don't know
> what parts still need attention and in what ways.
> 
> If you or anyone still thinks this version isn't right, please reply
> with some OLD/NEW-style specific edits for me to make.  Otherwise I'm
> inclined to agree with Andrew and circulate it to apps-discuss and
> perhaps saag and dnsop soon.

See below:

> determining whether two domain names are related. A popular example is
> the need to determine whether example.com and foo.example.com, or even
> example.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 currently
> 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".

> Prior solutions for identifying relationships between domain names
> have relied primarily upon the DNS namespace and protocol to provide
> a service that actually exists outside of both. Relying on the DNS
> to do so thus renders such solutions unreliable and unnecessarily
> 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.

Both of these examples are /within/ the protocol.  That runs contrary to
the opening assertion of this paragraph.  Other than the PSL, I've no
idea what other 'prior solutions' are being cited.  I doubt a non-expert
(or possibly expert) reader will, either.

> 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).

> 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

The way org domain is introduced here looks interesting.  The problem is
the surrounding text.

The PSL web pages don't use the term 'private' and don't really explain
what they mean by 'public'.  Presumably they thought it obvious.  Worse,
their basic definition is pretty vague:

     A 'public suffix' is one under which Internet users can directly
register names.

In fact, given the policies for some newer registries, I suspect this
language is actually wrong.  At the least, it's not clear what "public"
and "private" mean for some of those newer TLDs.

A bit of later PSL text is more concrete and pragmatic, though still a
bit odd:

      the highest level at which a domain may be registered for a
particular top-level domain

The text that I originally offered for the charter, to explain
'organizational domain' was:

is "inside" the organization.

So with all that, I'll suggest adding some text above the PSL paragraph
and below the RRTYPES paragraph:

     An 'organizational domain' is 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.

> organizational domain name (at some point in the namespace above it),
> of policy regarding that FQDN can be found. With respect to the
> and constraints of the namespace tree.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 30 Nov 2014 21:29:10 -0800

> (or possibly expert) reader will, either.

Both of those are examples of something happening via the protocol to try
to discover something that exists completely outside of the protocol, and
it doesn't work.  That's what the cited paragraph is trying to say.

> administrative authority to another that is "inside" the organization.

Added.

-MSK