Subject: [dbound] On (not) moving forward

From: "Resnick, Pete" <[email-masked]>
Date: Sat, 19 Mar 2016 20:31:37 +0000

Colleagues,

Your co-chairs and supervising AD have been discussing the apparent lack of progress toward setting definitive milestones for the DBOUND working group.

Since chartering almost a year ago, three proposals have been submitted to the WG for consideration.  While the authors of those documents have our thanks for the effort put into producing them and keeping them alive, no clear consensus has developed to proceed with any of them.  Indeed, there is not even consensus on the problem statement document.

At this point, we would like the working group to consider and discuss why we appear to be entrenched, and what might get us moving.  Are there resources we need that we don't have?  Is there additional expertise we should recruit?  Are apathy and NIH (Not Invented Here) the only problems?

We feel this is work the IETF really should be doing.  If it does not, industry will be left to come up with its own solution to the problem. We trust we don't need to recount for anyone reading this what an unpleasant experience we had When industry felt that the IETF had failed it in terms of email security and created and imposed DMARC.

Obviously the above cannot, in the absence of visible progress, sustain the existence of the working group indefinitely, so we would like to encourage progress somehow.  Failure to do so will obviously result in termination of the working group. Attempting to re-create it later when we think there's momentum again will be more difficult as we'll have to convince the IESG that things will be better.  Another option is to try to reassign the problem to the DNSOP working group (with the same impetus we described above) and see what they propose.

Please reply on this thread with suggestions to get the WG moving.  If you are an author, perhaps you should revitalize discussion of your draft.  If you have never commented on any document, such comments would be very valuable now.  If you have suggestions for others whose opinions we should seek, please suggest them.  If there are useful resources your co-chairs should seek, please request them.

We are at your service,

Pete & Murray, DBOUND co-chairs

---

From: "John Levine" <[email-masked]>
Date: 20 Mar 2016 00:39:53 -0000

>At this point, we would like the working group to consider and discuss why we appear to be entrenched, and what might get us moving.

I've been scratching my head, too.  As best I can tell, this is one of
those problems where the more you think about it, the more twisty
passages there are.  So perhaps a revised goal would be to ask what is
a minimal design that would still be better than downloading the PSL?

I shamelessly argue that my draft is probably it.  The lookups are
fast, one plus the number of boundaries in a name (not the number of
name components), the names can be self-published within the domain's
tree, or in a third party tree, and it can handle different
applications with different boundaries.

The Decchio draft requires a new _odup top-level domain which I think
makes it a non-starter, and the lookup process is so complex I don't
entirely understand it but it appears I think it can involve tree
walking.  (Casey said that he had another version without a separate
TLD, but if he's posted it I can't find it.)  The Yao draft still has
problems with wildcard semantics.

I'm not arguing mine is perfect; Deccio can identify both boundary
domains (co.uk) and organizational domains (example.com) which I
don't, my organizational domains are implicit, so we might want to add
some of his qualifiers.  

Andrew's always wanted to do cross-tree relationships, e.g.,
example.org is the same as example.com, but as far as I know nobody's
come up with a way to do that without putting boundary records on
every name in a subtree that might be related to something else.

So how about if we pick a draft, preferably mine, and say either it's
good enough to move ahead, or else say why it isn't.

R's,
John

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 21 Mar 2016 10:13:04 +0800

From: Resnick, Pete
Date: 2016-03-20 04:31
To: [email-masked]
Subject: [dbound] On (not) moving forward

[Jiankang Yao] yes, agree. another example or use case is that simplified Chinese version and tradtional Chinese version of .China IDN TLD can use dbound to tell the application or users that  the same label under both versions of .China IDN TLD belong to the same registrant and share the same administrative policy.  

I think that it is also true for .NGO and .ONG TLDs. These 2 TLDs are supposed to have a bundled name registration.  Many users will like to have the names under these 2 tlds share the  same administrative policy.

[Jiankang Yao] I think that the WG may push or focus on the problem statement first .

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2016 02:43:12 -0000

>.China IDN TLD can use dbound to tell the application or users that  the same label under both versions of .China IDN TLD
>belong to the same registrant and share the same administrative policy.
>
>I think that it is also true for .NGO and .ONG TLDs. These 2 TLDs are supposed to have a bundled name registration.

You are correct here.  (I know since I have a .NGO/.ONG domain.)

This points out that there are two different kinds of cross-tree
relationships that are of interest.  One is the kind of relationship
you described, parallel subtrees, so it would be useful to have some
way to say that 

  <name>.ong and <name>.ngo

are under the same control for all names.

Another point that Andrew made a while ago is that there are often
multiple domains under the same control with no syntactic relation.
For example, the domains google.com and 1e100.com are in fact run by
the same people, even though the names aren't related.

For the parallel subtrees, I'm wondering whether the points of
relation are all at the TLD and if so, some limited kludge would do
the trick.  Hmmn.  I also wonder how important it is in both cases to
handle relationships among more than two trees.  For example. the Indian
ccTLD controls .in .ভারত .భారత్ .ભારત .भारत .بھارت‎ .ਭਾਰਤ and .இந்தியா.
I don't know whether they're all supposed to be equivalent or whether there
are separate registrations in each.

R's,
John

---

From: Gervase Markham <[email-masked]>
Date: Mon, 21 Mar 2016 10:47:05 +0000

On 20/03/16 00:39, John Levine wrote:
>> At this point, we would like the working group to consider and
>> discuss why we appear to be entrenched, and what might get us
>> moving.
> 
> I've been scratching my head, too.  As best I can tell, this is one
> of those problems where the more you think about it, the more twisty 
> passages there are.  So perhaps a revised goal would be to ask what
> is a minimal design that would still be better than downloading the
> PSL?

I've been lurking on this list but I don't feel I have much to add to
the discussion - because while I am part of the team that maintains the
PSL, I don't have a good grasp of the capabilities of the alternative
technologies which are being proposed as foundations for replacing it.

However, it does strike me that "being better than downloading the PSL"
is actually a higher bar than one could think, because any online
technology starts (at least, from the point of view of many
implementers) with the handicap of requiring some number of additional
time-consuming network lookups. So it has to be quite a bit better in
other ways to be better than the PSL overall.

I wonder if the continued persistence of the PSL is a good example of
"worse is better"?
https://en.wikipedia.org/wiki/Worse_is_better

Perhaps a design goal of the new system (and I don't know which, if any
drafts, meet this goal) would be the ability to somehow scan the live
information across the entire Internet and re-construct the PSL on a
regular basis for those applications for which regular network lookups
are too costly?

Gerv

---

From: Casey Deccio <[email-masked]>
Date: Mon, 21 Mar 2016 15:05:47 -0400

On Sat, Mar 19, 2016 at 8:39 PM, John Levine <[email-masked]> wrote:

> So perhaps a revised goal would be to ask what is

"Better" is a very ambiguous and subjective term.  A number of desirable
solution characteristics have been discussed on the mailing list and in
meetings, whose use here would be more appropriate.

> makes it a non-starter

s/Decchio/Deccio/

The -02 version will not require a new _odup TLD.  The -02 version is
nearly ready to be published, but is still undergoing internal review.

> and the lookup process is so complex I don't
> entirely understand it

I have yet to see an in-depth review of the draft from you.  The mechanism
in the -02 version is nearly the same as it is in the -01 version, with the
exception that the client begins the lookup process at the TLD (e.g., _
odup.com.) rather than at the root.  So you can still start your review
with the -01 version until -02 is ready, given this understanding.

One of the strongest characteristics of the approach in the Deccio draft is
careful consideration of existing behaviors to preserve compatibility with
current (i.e., PSL) solutions.  Any perceived complexities from the
approach likely result from that.  The algorithm itself is actually
straight-forward: walk (i.e., using DNS queries) the name downward from its
TLD to identify 1) the organizational domain for the name and 2) the policy
associated with the name.  The responses to each query (e.g., NXDOMAIN,
NODATA, +bound, +org) indicate which DNS name to query next in the walk
downward.

There are plenty of examples in the document, in the form of example names,
ODUP statements, lookup sequences, and resulting policy.  There is also
example code at: https://github.com/verisign/odup

(With the -02 version of the draft the example code will also be updated.)

A few other comments on the -02 version (to be published...) of
draft-deccio-dbound-organizational-domain-policy:

- Bootstrapping - As mentioned previously in this message, bootstrapping
the lookup process begins with the TLD, not with the root.  Each TLD hosts
a "_odup" subdomain which is consulted for policy information for
subdomains of the TLD itself.  There is no longer a notion of a _odup TLD.
- Fetch - The "+fetch" directive allows clients to download policies of
TLDs and arbitrary (e.g., high use) domains ahead of time to avoid the
real-time lookup, which can be expensive.
- PSL reproduction - Gerv mentioned reconstruction of the existing PSL.
This is inherent in the design of the -02 version of the draft.  Whether
for performance enhancement or for backwards compatibility with
applications currently using the PSL, the PSL can be reproduced from ODUP
statements at TLDs (and other domains), just as the ODUP statements at TLDs
(and other domains) can be created from the PSL.  This is an essential
characteristic of a usable solution.  Note that the code to be published
alongside the -02 version of the draft demonstrates this capability.

Cheers,
Casey

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2016 16:15:08 -0000

>regular basis for those applications for which regular network lookups

DNS caches get you a lot of that already.

R's,
John

---

From: Casey Deccio <[email-masked]>
Date: Mon, 21 Mar 2016 16:20:45 -0400

> DNS caches get you a lot of that already.
DNS resolvers retrieve and cache information on-demand when queried for it
by clients.  That means there is still a penalty 1) for the initial and
subsequent cache misses and addtionally 2) for every lookup from
application to DNS resolver.

Casey

---

From: Jothan Frakes <[email-masked]>
Date: Mon, 21 Mar 2016 13:29:32 -0700

+1 to John's comment

And something to consider wrt Casey's point

On Mar 21, 2016 1:20 PM, "Casey Deccio" <[email-masked]> wrote:
> DNS resolvers retrieve and cache information on-demand when queried for
it by clients.  That means there is still a penalty...

..and potential "intervention" vector where zones may not be utilizing
DNSSEC

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2016 17:13:46 -0400

> application to DNS resolver.

Yes, but on any sort of reasonably busy system the cache will be on the 
same host or at worst a fast LAN hop away so it's pretty quick.  Compare 
that to the cost of periodically sucking down and parsing and storing the 
text PSL and it seems pretty clear that which one is faster depends 
entirely on the application and details like how you store the parsed 
PSL.

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 21 Mar 2016 14:38:08 -0700

On Mon, Mar 21, 2016 at 2:13 PM, John R Levine <[email-masked]> wrote:

> entirely on the application and details like how you store the parsed PSL.
>

There have also been some assertions in past F2F discussions about some
value in supporting off-line cases to determine boundaries, though I am
unconvinced that is a use case that we should worry about.

--Kurt Andersen

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2016 21:38:01 -0000

>> application to DNS resolver.

More to the point, self-publishing in the DNS has different semantics
from third-party publishing by someone like Mozilla.  I think the
people at Mozilla are doing a good job at a thankless task, but
self-publishing has a lot to recommend it.

R's,
JOhn

---

From: Casey Deccio <[email-masked]>
Date: Mon, 21 Mar 2016 17:50:11 -0400

> unconvinced that is a use case that we should worry about.

Please remember that offline usage is the status quo!  It seems like a
pretty big assumption that we need not worry about "offline cases" when
that is our starting place.

Casey

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 22 Mar 2016 17:09:06 +0900

> are separate registrations in each.

They are different scripts, used for different languages in India. 
Although I don't know what exact policy will be applied, it wouldn't 
make much sense to have e.g. an Arabic-script (Urdu language) 
second-level name after the Tamil TLD (.இந்தியா), and so on. So 
definitely the subtrees won't be the same, and the chance that the same 
second-level label turns up in multiple subtrees seems slim. Also, as 
https://www.registry.in/Internationalized_Domain_Names_IDNs indicates, 
these TLDs seem to be activated in a staged fashion, with .भारत 
(Devanagari Script, used for Hindi, India's most popular native 
language) being first. So at least for some time, there won't be any 
equivalents on the second level, either.

What may happen, for some of the second levels, is that the parallelism 
between the Indic scripts is used. This is already the case for these 
TLDs, in that four of them (
भारत, Hindi,     U+092D 093E 0930 0924;
ভারত, Bengali, U+09AD 09BE 09B0 09A4
ਭਾਰਤ, Gurmukhi, U+0A2D 0A3E 0A30 0A24;
ભારત, Gujarati, U+0AAD 0ABE 0AB0 0AA4, see 
http://www.iana.org/reports/2011/india-report-07jan2011.html for 
additional detials) are exact parallels of each other (with hex 80 
offsets), and a fifth,
భారత్, Telugu, U+0C2D 0C3E 0C30 0C24 *0C4D*, is very close but needs a 
final vowel killer sign. The remaining two, Arabic (completely different 
encoding) and Tamil (completely different language family, and therefore 
in this case using a different word) differ.

So similar relationships may hold at the second level, with the 
equivalent second level names using the script of the TLD, but in many 
(but not all) cases using codepoints with equal offsets. It will be 
interesting to see how registry.in handles the assignments of second 
level labels in the other ITLDs (besides भारत). For भारत, they seem to 
favor trade mark holders over holders of ASCII domain names in .in, and 
they might do something similar for the other TLDs (adding .भारत to 
.in). A lot of script parallelism may already exist for trade marks 
themselves.

In addition, if actually deployed (and not just used as an alias for an 
English or Hindi version of a site), it's very easy to guess that the 
actual content of each second-level domain would be in the language(s) 
that are written in that script, even if their content is (mostly) the same.

Regards,   Martin.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 23 Mar 2016 17:24:07 -0700

Here is a hopefully-useful view:

- There is a current solution that solves most of the problem space. It 
is managed by "volunteers" and works OK.

- The WG has seen two new proposed solutions that solve some more of the 
problem space. Both allow management by individual zone owners.

- If the WG closes without standardizing on one of the proposed new 
solutions, the highest risk is that the volunteers running the current 
solution stop. The world also loses the extra problem space coverage, 
but that doesn't seem to be so significant to the world.

- If one or both proposed solutions is deployed in addition to the 
current solution, the highest risk is that relying parties looking at 
multiple sources will get differing answers and won't know which to 
trust.

- There doesn't seem to be much interest in the new solutions from other 
than their respective authors. That is, we haven't seen much sign from 
the relying parties or their surrogates saying "we really need the 
bigger problem space" nor "we need to get the information in a different 
way".

Personally, I am mostly concerned with relying parties getting 
conflicting information, and that seems inherent in any transition from 
the current solution to either of the proposed ones (or, worse, to both 
of the proposed ones at the same time).

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 21:03:08 -0400

On Mon, Mar 21, 2016 at 02:43:12AM -0000, John Levine wrote:
> relation are all at the TLD

No; indeed, your mail contained an example of how not.  Those other
cases are, IMO, actually considerably more important.

I will note that _none_ of the proposals really solves the parallel
subtrees case in its full implications.  A very early version of the
proposal I've written had some hints about how to achieve that, but I
pulled it out.  Part of the reason I did was because it was
inadequate, because

> ccTLD controls .in .ভারত .భారత్ .ભારત .भारत .بھارت‎ .ਭਾਰਤ and .இந்தியா.

of things like that.  What you really need to make sensible registry
policy decisions is the blocked/allocatable/allocated/delegated data
that is implicit in the LGR (and lager) work.  The natural place to
have gotten that would have been RDAP whenever it made sense, which
was why I thought an SRV entry or something would have been nicer than
the IANA registry we ended up with (since those won't scale).  I'd
like to think that example is a cautionary tale about trying to do too
little, but I don't expect we'll take it that way.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 21:16:07 -0400

> regular basis for those applications for which regular network lookups

That very analysis is behind some of the interations of the proposal
that Jeff and I have made.

The basic idea is that a PSL-style list is going to be a permanent
feature, because even one additional lookup at resolution time for
interactive users (e.g. web browsers) will always be a non-starter.

The idea behind the SOPA record is that such lists then become
self-maintaining.  You get an initial static one when you install a
browser.  It is presumably bootstrapped by using the PSL and then
checking the PSL against what's in the DNS.

Over time, browsers and other tools can do the SOPA lookups
opportunistically and in the background, according to the sites the
user frequents.  There are multiple benefits from this:

    1.  The maintenance of the information comes to be better aligned
    with the actual operators of the zones.

    2.  Corrections do not depend on the PSL update cycle + the
    browser update cycle, but become available almost as soon as some
    user visits a site.

    3.  (Maybe 2.a.) The maintenance of the PSL can become fully
    distributed the way the DNS is.

    4.  New, more sophisticated policies within sites become possible
    that were not possible before.

(4) is a long-term happy story, not a short term one, but I think it
is a feature that provides a virtuous circle that allows the new
properties to become available.  1-3 are the short term features that
allow incremental deployment.

We've tried to make this clear in the draft, but I guess it isn't or
the questions wouldn't persist.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 25 Mar 2016 21:27:00 -0400

On 25 Mar 2016, at 21:16, Andrew Sullivan wrote:

> self-maintaining.

I’m sympathic to this solution, but as you may remember, we could have 
chosen a DNS new RR for RDAP and people were against because it means 
updating software (and also limited sandboxing in javascript browser 
environment) and nobody believe it would be done or deployed. I think we 
both agree that an in-DNS solution was better for RDAP and could be the 
best for dbound.  So I’m asking the same question we had for RDAP: 
while an in-DNS a good solution, does it have the problem of finally not 
being implemented/deployed because of a new RR?

Marc.

> You get an initial static one when you install a
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 21:28:49 -0400

On Wed, Mar 23, 2016 at 05:24:07PM -0700, Paul Hoffman wrote:
> Personally, I am mostly concerned with relying parties getting conflicting
> information, and that seems inherent in any transition from the current
> solution to either of the proposed ones (or, worse, to both of the proposed
> ones at the same time).

But part of the problem is that the existing system often gets things
_wrong_, which is one of the things that caused me to start work on
this in the first place (and which has been pointed out in every
version of the drafts -- first that I put together and that Jeff and I
then put together).  There have been names in the PSL list that don't
accurately reflect the registry (i.e. zone operator) policy for how
that name worked.  For instance, there were at one time several museum
names on there that were actually empty non-terminals and not suffixes
of any kind.  Closer to home for me, there were names on the PSL that
Dyn (my employer) hadn't used in some time for delegation (since
fixed, I believe).

This is not to criticise anyone, but instead to make the same point
I've been making for some years now: if you want to make assertions
about names in the DNS, then the place to make those assertions is in
the DNS, both so that you get the semantics right automatically and so
that when the DNS-administrative boundaries change, the people who
have the authority to make the assertions needed are the people
actually in control of the domain name.  That's the reason this WG was
chartered in the first place, I think, and the problem is still with us.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 21:43:02 -0400

On Fri, Mar 25, 2016 at 09:27:00PM -0400, Marc Blanchet wrote:
> in-DNS a good solution, does it have the problem of finally not being
> implemented/deployed because of a new RR?

The difference between RDAP and SOPA has to do with the incentives for
deployment.  (The RDAP case could in fact have been solved by SRV, if
you ask me, but it was quite clear that the WG didn't want to do it.)

The SOPA draft defines the default case as, "Nobody is in the same
policy realm as me."  For a large number of sites, this is
exactly the right answer.

The SOPA draft says you can make the explicit claim, "Nobody is in the
same policy realm as me."  That has certain advantages, such as
caching and so on, which means that it's the right answer for public
suffixes.  Since they're the people who have the greatest potential to
deploy new RRs, there's a positive effect.

The SOPA draft gives you a way to make more significant statements
about others being in the same policy realm.  There is a barrier to
new RRs here, but there are mitigating factors: (1) the sites that
want this sort of functionality are more sophisticated, so they are
the more likely to be able to deploy new RRs; (2) the lookup story
doesn't need to be perfect for consumer-end hosts, because of the plan
to fall back to browser-distributed files as well (which now get the
benefit of automatic crowdsourced maintenance); (3) an important part
of this story is the CA checking when issuing certs, which benefits
from the new RR even if consumer-end hosts.

Finally, I do, very much, think that things like SOPA would be way
easier to deploy if we did something like John's RRTYPE
pattern-classification stuff.  That has kind of gone nowhere, but
partly because the demand is stanched by the constant refrain that new
RRs are impossible to deploy.  I'd be prepared to update the SOPA
draft with a normative dependency on draft-levine-dnsextlang-07 if we
think it would help.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2016 02:56:52 -0000

>being implemented/deployed because of a new RR?

Both my proposal and Casey's uses a distinctive tag in the DNS names,
so they could both work either with a new RRTYPE or using TXT records.

SOPA needs a new RRTYPE.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 23:02:41 -0400

> so they could both work either with a new RRTYPE or using TXT records.

Yes.  And as a result, they can't make claims about that owner name
itself.  This point is made in the SOPA draft.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 25 Mar 2016 19:10:04 -0700

On 25 Mar 2016, at 18:28, Andrew Sullivan wrote:

>> conflicting
> _wrong_,

We fully agree here. I even agree with the placement of your proposed 
solution: in the DNS, where the administration actually happens. 
However, that doesn't negate my concern: when the second solution is 
(slowly) ramping up, there will be two sources of information, and the 
older one will be much fuller (even if some of that fullness is wrong).

My response in this thread was "on moving forwards", not "on how to move 
differently".

--Paul Hoffman

---

From: "Marc Blanchet" <[email-masked]>
Date: Sat, 26 Mar 2016 09:01:46 -0400

> so they could both work either with a new RRTYPE or using TXT records.
TXT records are way too overloaded. bad design. we shall stop using TXT 
records for extending the DNS.

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2016 10:38:04 -0400

> records for extending the DNS.

You can't have it both ways.  For applications with distinctive tags like 
DKIM where the names aren't shared with other kinds of records, TXT works 
fine.  If we adopt something like what Casey or I have proposed, we can do 
that.

On the other hand, if we want to use new record types, we need to face the 
fact that deploying new types in practice is hard.  (And "deploy" means a 
lot more than installing a new version of BIND.)  This seems unlikely, 
since recent messages remind us that a lot of the DNS community remains in 
deep denial about what the real problems are.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 26 Mar 2016 14:19:26 -0400

On Sat, Mar 26, 2016 at 10:38:04AM -0400, John R Levine wrote:
> lot more than installing a new version of BIND.)

Agreed.

> This seems unlikely, since
> recent messages remind us that a lot of the DNS community remains in deep
> denial about what the real problems are.

Where were these messages?

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Sat, 26 Mar 2016 16:15:36 -0700

On Mar 26, 2016, at 6:01 AM, Marc Blanchet <[email-masked]> wrote:
> TXT records are way too overloaded. bad design. we shall stop using TXT records for extending the DNS.

Agreed that it's a bad design, but I thought the debacle with the SPF RR and the continued assertions that it is too hard to deploy new RRs guaranteed we'd be using TXT records in the future (at least for anything that is expected to scale).

Regards,
-drc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 26 Mar 2016 16:20:15 -0700

> Where were these messages?

Starting on February 9, the RFC6686 debate happened again on the SPFBIS
list.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2016 20:34:44 -0400

> Agreed that it's a bad design, but I thought the debacle with the SPF RR and the continued assertions that it is too hard to deploy new RRs guaranteed we'd be using TXT records in the future (at le…

SPF was an unusual situation since there was already a lot of running code 
using TXT records.  But the people running that code had already gone 
through a lot of pain to get provisioning systems to handle TXT records, 
and they correctly saw that there was no benefit whatsoever to them to 
switch their working code to yet another RRTYPE.

So long as the DNS crowd remains hostile to doing anything to make it 
easier to deploy new RR types, yeah, it'll keep being too hard.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Mar 2016 18:00:07 -0700

On 3/26/2016 4:15 PM, David Conrad wrote:
> On Mar 26, 2016, at 6:01 AM, Marc Blanchet<[email-masked]>  wrote:

TXT records, under an _underscore-based naming scheme, works just fine. 
  Deploys easily.  Has no usage conflicts.

SRV.  DKIM. Etc. Etc. Etc...

Oh, and ummmmm...

      https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 26 Mar 2016 18:05:00 -0700

> TXT records, under an _underscore-based naming scheme, works just 

...but only if there is no zone cut where you want to put them. As 
Andrew pointed out upstream, some of the use cases for DBOUND require 
that an owner be able to say "at this node, ...", not "at the node above 
me, ..." because the responsible party can't put records at the node 
below them.

> SRV.  DKIM. Etc. Etc. Etc...

Fully agree on that. I'm in the pro-TXT fold as much as I'm in the 
new-RRtype-if-you-need-it fold.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Sat, 26 Mar 2016 19:21:08 -0700

John,

On Mar 26, 2016, at 5:34 PM, John R Levine <[email-masked]> wrote:
> SPF was an unusual situation since there was already a lot of running code using TXT records. But the people running that code had already gone through a lot of pain to get provisioning systems to handle TXT records, and they correctly saw that there was no benefit whatsoever to them to switch their working code to yet another RRTYPE.

I suspect all of these arguments will be reused.

> So long as the DNS crowd remains hostile to doing anything to make it easier to deploy new RR types, yeah, it'll keep being too hard.

I'm unaware of hostility. I am aware of interests, particularly in the (generally non-DNS) folks who write the web GUI front ends to DNS provisioning systems, to not write any more code than they have to. But perhaps you know different people than I.

Regards,
-drc

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Mar 2016 20:37:52 -0700

> me, ..." because the responsible party can't put records at the node

The semantic of an underscore branch to domain foo is that it provides 
attributes associated with foo.  The "above me" is built into the 
construct, so that the semantic of data in the underscore branch is not 
"above me" but rather is "here are some attributes associated with foo.

I understand the administrative issues that you cite.  However the 
operational difficulties in creating name entries in the DNS are 
generally significantly less in effort and time than in getting a new RR 
to be useful, end-to-end...

By some orders of magnitude.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 27 Mar 2016 00:07:06 -0400

> I'm unaware of hostility. I am aware of interests, particularly in the 
> (generally non-DNS) folks who write the web GUI front ends to DNS 
> provisioning systems, to not write any more code than they have to. But 
> perhaps you know different people than I.

We GUI front end writers would like something like my dnsextlang proposal 
so the front ends could automatically configure themselves to handle new 
RRs.  It has been kicking around for at least five years, no WG has picked 
it up yet.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 27 Mar 2016 12:19:51 -0400

On Sat, Mar 26, 2016 at 08:37:52PM -0700, Dave Crocker wrote:
> attributes associated with foo.

But I, at least, was trying to design something that could apply to
any name.  There's a recursive problem with underscore labels for this
use, because by defition they can't work for every case (at the very
least, they can't work once the name you're trying to talk about is
already 253 octets long)

> operational difficulties in creating name entries in the DNS are generally
> significantly less in effort and time than in getting a new RR to be useful,
> end-to-end...

I'm aware of the difficulties.  See upthread where I talk about the
deployment incentives and where the pain happens.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Gervase Markham <[email-masked]>
Date: Mon, 28 Mar 2016 09:49:55 +0100

On 24/03/16 00:24, Paul Hoffman wrote:
> solution stop. 

That's a fairly small risk; as the data is open, someone else could just
start. In this unlikely event, there would perhaps be a risk of
fragmentation (multiple competing sources of truth).

However, as PSL maintainer, if we were to reach a stage where I and
Mozilla were no longer interested in or available to maintain it, I
would try and make sure it was handed over well.

Gerv

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Mar 2016 06:26:25 -0700

> fragmentation (multiple competing sources of truth).

I think there's a risk of fragmentation already.  Someone who doesn't like
a choice you make about an entry that gets added (or omitted) could start
doing their own now.  There certainly are a lot of DNSBLs around, for
example.  Then people would have to decide which PSL they want use, or how
to aggregate the results after consulting both.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 13:47:28 -0400

On Mon, Mar 28, 2016 at 06:26:25AM -0700, Murray S. Kucherawy wrote:
> I think there's a risk of fragmentation already.

At either an APPSAWG meeting or the BoF that got us started, Phill
Hallam-Baker asserted that Comodo was already using its own private
version with different properties.  So in some realms, we have claims
of fragmentation today.

As a practical matter, we'll continue ot have that, since people will
make their own decisions about what they are willing to believe or
accept.  But I claim that it is better to start with data from the
authoritative operator of a given name than from anywhere else.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Mar 2016 07:13:19 -0700

First off, I wasn't suggesting that the volunteers running the current 
solution stop" was much of a risk: it was just the biggest risk I could 
see for the the WG closing without standardizing on one of the proposed 
new solutions. Mozilla has a good reason to keep doing the work.

> to aggregate the results after consulting both.

Murray's point is a good one, but that's not necessarily much of a 
negative risk. If the "main" PSL continues to be updated, anyone 
choosing a fork of the PSL has to have a good reason to do so. I can 
think of some good reasons that might come up, but as we all know, the 
chance that even a well-maintained fork could overtake the main one in 
under a decade are slim.

Having said that: if this WG adopts one *or even multiple* of the 
proposals as Experimental RFCs. and even if just a handful of zone 
maintainers adopt some of them, Mozilla could use those as input to its 
own PSL. If Mozilla chooses not to do that, forking the PSL at 
https://github.com/publicsuffix/list and using the scraped data would be 
a very low-effort work, and if people coalesced around one fork, Mozilla 
might say "hey, that's a good idea" or a contingent of users would just 
use the fork.

This might be a good enough reason for DBOUND to move forward with a 
different charter. Instead of picking one solution for Standards Track 
with the too-little energy that we seem to have, we could:

- Informally help the authors to get the four drafts down to two or 
three

- Get some more review so that the authors can put more "why this 
proposal might not work for you" sections in their documents

- Send them all to the IETF as Experimental at the same time

I know that some people find this kind or resolution to IETF efforts to 
be a failure. Because these could be input to the PSL, or to a popular 
fork of the PSL if needed, I think this is actually worth our time and a 
bit more effort.

If others like this idea, I'm willing to work on charter text. If others 
thing I'm crazy, I'm willing to sit here quietly.

--Paul Hoffman

---

From: Simone Carletti <[email-masked]>
Date: Mon, 28 Mar 2016 16:22:21 +0200

> to aggregate the results after consulting both.

While this risk exists in theory, in practice the probability that this
will happen is low. The risk is generally more relevant in softwares, but
the PSL is a definition list. As long as there is consensus among the major
consumers and cooperation with the suffix owners (and this also largely
depends on the maintainers), the master list will continue to be relevant
and the primary point of interest.

Forks exist, but they generally solve specific needs of single individuals.
There is honestly very little interest and gain you can get by using
someone else fork.

Conceptually, it's like the HSTS project. I can grab the list and add my
entries, but it will be totally useless as Chrome/Mozilla/Safari will
continue to use that list, hence mine will have no effect. And because my
fork is mostly irrelevant for anybody else, any other publisher will likely
use the original HSTS list instead of mine. So I eventually will submit my
changes to the primary list.

Best,
-- Simone

Disclaimer: I'm a contributor to the PSL.

-- 
Simone Carletti
Passionate programmer and dive instructor

https://simonecarletti.com/

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 29 Mar 2016 10:53:33 +0900

On 2016/03/28 23:13, Paul Hoffman wrote:

> own PSL.

The Mozilla part is the easy part. Essentially, a script in Python or 
Ruby or some such would do the job. And once it was established, the 
people maintaining the PSL might sooner or later start telling the DNS 
operators "why don't you just publish a record, that would save us some 
work".

The problem would be with the operators. It's quite possible that DNS 
operators would start adding such records if there's a standards track 
spec. I could even imagine them to be motivated to add the relevant 
records if there is *one* experimental spec. But multiple experimental 
specs? Not a splitter of a chance, if you as me.

So I think we better pick one solution. I'd think my main criteria would 
be 1) any major DNS operator voicing support for it (or already working 
on something like it), and 2) as simple as possible, but easily 
extensible in the future.

> fork of the PSL if needed, I think this is actually worth our time and a

Doing multiple experiments may be a very good idea in some cases. It 
just doesn't look to me like it would work in our case.

Regards,   Martin.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Mar 2016 19:09:25 -0700

> specs? Not a splitter of a chance, if you as me.

Why not? If they only had to pick one of three, why is that harder than 
picking one of one?

> So I think we better pick one solution. I'd think my main criteria 
> would be 1) any major DNS operator voicing support for it (or already 
> working on something like it), and 2) as simple as possible, but 
> easily extensible in the future.

So far, this WG hasn't been able to do #2. And I'm not sure what you 
mean by #1. What is a "major DNS operator" in this context?

--Paul Hoffman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 30 Mar 2016 06:44:21 -0700

On Mon, Mar 28, 2016 at 7:09 PM, Paul Hoffman <[email-masked]> wrote:

>> spec. I could even imagine them to be motivated to add the relevant records
>> if there is *one* experimental spec. But multiple experimental specs? Not a
>> splitter of a chance, if you as me.
>>
>

A desire to interoperate, I would imagine.  I would want to pick the same
one other operators will use, and that other clients will use.  Otherwise,
to be sure of participation, I have to implement all three.

-MSK

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Mar 2016 16:55:59 -0300

On 30 Mar 2016, at 10:44, Murray S. Kucherawy wrote:

>>> records

For the scenario I gave (either Mozilla or someone with a fork of the 
PSL wanting to supplement the current PSL input with DNS records), 
implementing all three seems to not be a lot of work. We would only need 
to pick one if we wanted everyone to interoperate, but it feels like 
that idea is off the table.

--Paul Hoffman

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 31 Mar 2016 12:18:46 +0900

> to be sure of participation, I have to implement all three.

Yes indeed. Also, increased choice increases the risk that the answer to 
"which one to choose" is "none" or "let's wait and see".

Regards,   Martin.

P.S.: I agree that in the scenario that Paul brought up, implementing 
the consumer side isn't that much of an issue. What I'm talking about is 
the 'producer' side, including also the upgrades to bind or whatever 
software is used.

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 31 Mar 2016 14:20:35 +0800

From: Martin J. Dürst
Date: 2016-03-31 11:18
To: Murray S. Kucherawy; Paul Hoffman
CC: [email-masked]
Subject: Re: [dbound] On (not) moving forward

>"which one to choose" is "none" or "let's wait and see".

I think that "Choose none, wait and see" is not a problem. 
 This kind of patient user can wait for the standard track solution and then deploy it. 

"Experimental " indicates that some users (pioneers) will use and taste them first, and then decide which solution is better based on usage experience, which will help the standard track rfc to be published.

Jiankang Yao

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2016 17:03:09 -0000

While it's great to see all this metadiscussion, is there any chance
the discussants could read the three drafts and let us know what you
think of them?

R's,
John