Subject: [Dbound] Names of domains

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 14 Nov 2014 00:07:12 -1000

I hate the name PSL and this is just a copy of what I wrote into the jabber room today. 

In general the appropriate DNS terms are “Delegation domain” i.e. domain that gives out delegation domains 
as that is quite broad and can cover almost any non-leaf domain I would suggest “Open Delegation Domain”. 

For the inverse we do not have a good term I have been using “Vanity Domain”  or “Closed Domain”. 

So PSL should be renamed to "ODD list”

     Olafur

---

From: Gervase Markham <[email-masked]>
Date: Fri, 14 Nov 2014 14:13:34 +0000

> I hate the name PSL and this is just a copy of what I wrote into the jabber room today. 

Hey, at least we don't still call them "Effective TLDs". That name was
_not_ popular... :-)

Gerv

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 14 Nov 2014 07:20:34 -0800

I was encouraged by the BoF dialog this time.

Folks get too caught up channeling their energy and passion towards
trashing the Mozilla PSL or the term "Effective" historically.

This time there was more actual constructive dialog around focusing on use
cases and what the problems are that were in such need of solving that PSLs
are created or used in the first place instead of focusing on the fact that
they are created, starting with the IANA PSL and building upon it.

Jothan Frakes
Tel: +1.206-355-0230

On Fri, Nov 14, 2014 at 6:13 AM, Gervase Markham <[email-masked]> wrote:

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Nov 2014 17:10:37 -0500

> In general the appropriate DNS terms are “Delegation domain” i.e. domain that gives out delegation domains 

No, that's not the appropriate DNS term.  Not all names that are
"public" perform delegation.  For instance, my employer does not add a
delegation below dyndns.org when you register example.dyndns.org.

Indeed, this is another instance of the same old mistake, which is
reading some relationship between DNS administrative details and
policy boundaries.  They are completely orthoganal to one another.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Nov 2014 14:18:07 -0800

> policy boundaries.  They are completely orthoganal to one another.

hmm.  a possibly pedagogical moment:

  So, 'delegation' refers to zone boundaries, which are a matter of
operational convenience, rather than (necessarily meaning)
administrative independence?

  I thought that DNSSec had succeeded in fully confounding the otherwise
clean point that zones were strictly operational and didn't imply
administrative relationship.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Nov 2014 17:29:04 -0500

> administrative independence?

I'd prefer to say they're a matter of in-protocol distribution of
operations.  That does not tell you the relationsip between the two
sides of a zone cut.  To demonstrate this, issue the following two
queries:

dig -t SOA afilias-nst.info +noall +answer
dig -t SOA yyz1.afilias-nst.info +noall +answer

Those are both an apex, and they're plainly under the same
administrative control.  (I'm sure we can find more, but I happened to
know about these ones.)

> administrative relationship.

No, there was _always_ an administrative relationship, _of the DNS_.
You can't have a zone cut unless your parent agrees, because they have
to put NS records pointing to you in their zone.  But that does not
imply policy authority boundaries.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]