Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

From: "John R Levine" <[email-masked]>
Date: 29 Sep 2016 20:41:50 -0400

>The latter, is the decision-role of ICANN. Under advisement, yes.
>respecting IETF process yes. But the mechanism as written in 6761
>vests IETF with a process outcome which specifies where the label is,
>and what value. Thats just wrong.

For some version of wrong, I suppose, but it seems a false analogy to
me.  Nobody cares if their new RRTYPE is number 666 or numbr 273, or
what IP address range they get, but a lot of people care if their TLD
or pseudo-TLD is .lksjdk or .money.

R's,
John

---

From: George Michaelson <[email-masked]>
Date: Fri, 30 Sep 2016 11:03:03 +1000

Thats precisely why its NOT a false analogy: the design model in the
IETF is that the value doesn't matter, but in the DNS, the design
model is "follow the money" and 6761 crosses the bars: it enables
people in tech-space, to reserve labels in meat-space.

We got it wrong. We should have encouraged s/w designers not to brand
their DNS breakout string early, but provided a mechanism to give them
a token under .arpa, or something else, pending a decision, and we
should have made it clear the specific string wasn't their chosing. If
they see inherent value in the string, then they immediately walked to
being an applicant in ICANN gTLD space: the technical merit argument
doesn't relate.

Sorry John, but to me its not a "false analogy" its exactly what I
meant. 6761 is a process fail.

On Fri, Sep 30, 2016 at 10:41 AM, John R Levine <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Sep 2016 22:11:25 -0400

So, if anyone is still wondering why we need a /good/ problem statement,
this discussion is why.  You are both taking past reach other because you
are looking at only the part of the problem you care about.

On Sep 29, 2016 6:03 PM, "George Michaelson" <[email-masked]> wrote:

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Sep 2016 22:37:22 -0400

> are looking at only the part of the problem you care about.

... and why we need a Special Use Names problem statement, and not just a
RFC6761 problem statement. This problem is bigger than just 6761...

W

>
> On Sep 29, 2016 6:03 PM, "George Michaelson" <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On Fri, Sep 30, 2016 at 10:41 AM, John R Levine <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Sep 2016 23:04:13 -0400 (EDT)

On Thu, 29 Sep 2016, Warren Kumari wrote:

>       So, if anyone is still wondering why we need a /good/ problem statement, this discussion is why.  You are
>       both taking past reach other because you are looking at only the part of the problem you care about.
> 
> ... and why we need a Special Use Names problem statement, and not just a RFC6761 problem statement. This problem is
> bigger than just 6761...

I still do not see that. Without 6761, if anyone wants to ask for a TLD,
whether to delegate or never delegate, we (IETF) can say: That is
outside the area of our expertise - you must go to ICANN.

ICANN already has a blacklist of unsafe domains. IETF can advise them
on that list if needed.

I don't think at this point either ICANN or IETF would want to add TLDs
to the unsafe list. If at this point someone is still squatting domain
names, they get what they deserve. And all the known security risky
domains (as a result of decades of use of unqualified domain names)
are already known at ICANN, and they won't assign these. People creating
new ones are also going against the long standing don't squat advise,
and need no further protection from their own foot bullets.

So that brings the problem statement to:

 	IETF had the power to allocate or ban domain names based on the
 	Special Names RFC-6761. IETF no longer wants that power.

And the solution for that is a 6761bis document that confirms this.

Paul

---

From: "John R Levine" <[email-masked]>
Date: 29 Sep 2016 23:10:07 -0400

> are looking at only the part of the problem you care about.

Agreed.  It's also why the problem statement has to be as short as 
possible, like one sentence, so people can't read it multiple ways.

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Sep 2016 23:27:11 -0400

Okay, John, if you can state the problem in one sentence and not have
it just be your particular view of the problem, let's hear that
sentence.   Otherwise, can you stop with the hyperbole?

On Thu, Sep 29, 2016 at 11:10 PM, John R Levine <[email-masked]> wrote:
> Agreed.  It's also why the problem statement has to be as short as possible,
> like one sentence, so people can't read it multiple ways.
>
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 30 Sep 2016 00:38:00 -0400

> sentence.   Otherwise, can you stop with the hyperbole?

I did, back on Sept 18th.  Here it is again, slightly tweaked.  I realize 
that you don't like either of these, but at this point, so what?  Neither 
your draft nor the other one is getting traction, so evidently neither of 
them describe the problem that the group thinks we should solve.

... we'd be better off with a one or two sentence description of
what we're trying to do, perhaps along these lines:

   * Describe how and when to recognize domain names that are handled
   in ways other than the DNS.  (That's mDNS and .onion)

or

   * Describe how and when to recognize domain names that should not
   be delegated in the DNS. (That's mDNS and .onion plus the toxic waste.)

or maybe something else, so long as it's short.

R's,
John

---

From: Alain Durand <[email-masked]>
Date: Fri, 30 Sep 2016 05:17:30 +0000

On Sep 29, 2016, at 8:37 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

On Thursday, September 29, 2016, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

So, if anyone is still wondering why we need a /good/ problem statement, this discussion is why.  You are both taking past reach other because you are looking at only the part of the problem you care about.

... and why we need a Special Use Names problem statement, and not just a RFC6761 problem statement. This problem is bigger than just 6761...

We will have to agree to disagree. RFC6761 is the document that created this issue. Focusing on what is wrong running its process should be, IMHO, the first step. It is like: first, admit we have a problem.

Alain, speaking solely on my own behalf.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Sep 2016 17:54:17 -0400

The problem is that you are doing the same thing I was just talking
about: looking at the things you care about, and leaving out
everything else.

It's possible that there simply isn't energy to do this work, in which
case we definitely shouldn't do it.   But what we are trying to do
with our document was to try to break us outside the box of just
looking at this from our various individual perspectives, and instead
look at it from the broader perspective of as complete a set as
possible of the people who have reason to care about this issue.   I
still think this work is worth doing, but I will agree with you that
it does not appear that there are a lot of people on the mailing list
who have any enthusiasm for doing it.

If we were to do it, I really don't see the point in being
parsimonious in our descriptions of the proiblems.   We should be as
concise as possible, of course, but no more concise than that.

---

From: hellekin <[email-masked]>
Date: Sat, 1 Oct 2016 00:39:23 +0000

On 09/30/2016 01:03 AM, George Michaelson wrote:
> model is "follow the money"
>
> [snip]
>
> If they see inherent value in the string, then they immediately walked to

I'm sorry but you're saying that naming has a transaction value that
supersedes any other value, like historical or cultural.  Your ideology
is clearly visible, and mine is clearly opposite.  But you didn't
address anything technical by claiming that the market has the
totalitarian right to flatten anything that it touches.

Meanwhile, John R Levine claimed that the problem is related "to
recognize domain names that are handled in ways other than the DNS.", etc.

And Paul Wouters claimed that "IETF doesn't want [the power to suggest
names to ICANN] anymore", while Stephane Bortzemeyer claimed that no,
there's no problem with RFC 6761 since it was successfully used twice
already (RFC 6762 and RFC 7686).

I tend to agree with John and Stephane, but that doesn't make a problem
statement.  If we want to make something else of our lives than arguing
eternally about "this" 'problem', we should better try to simplify the
scope a bit.

1) there's a valid RFC 6761
2) it provides a working assumption that IETF WGs need to make a decision
3) P2P Names came with a bulk request that was refused
4) other drafts followed suite and jumped on the bandwagon
5) the WG started to argue that the provisions of RFC 6761 give too much
space to WG decision (and therefore conflicting perspectives)
5.1) some argued for more measurement, but then what measurements are
pertinent?  If size matters, then it discourages new networks to go
through IETF process; some things are not easily measurable; some things
have existed for a long period of time (how long is enough?); etc.
5.2) the .ALT draft was proposed to address part of the issue (e.g.,
non-exclusive, necessarily temporary 'self-assignments') but it also
uses RFC 6761 process
5.3) claim: RFC 6761 is fine, and it's on the WG!  But the WG can't find
consensus!
5.4) claim: let's reform RFC 6761 and define criteria!
5.5) claim: let's abolish RFC 6761!
5.6) claim: do we even need a Special Use Domain Name Registry?
6) .onion split from P2P Names to address a time-constraint, and was
accepted using RFC 6761 process
6.1) all other requests were frozen, pending resolution of "this" 'problem'
7) let's write a problem statement!
7.1) one problem statement was proposed
7.2) another one was proposed, with a different scope
8) here we are.

I don't think we need to insist on 5.*) because these points SHOULD be
part of the problem statement: are they covered by 7.1 and 7.2? Do the
problem statements need to address a larger scope? Can we decide at this
point that 3) and/or 4) can be addressed on a case-by-case, make them
part of the problem statement, and walk through them one by one to see
what is acceptable (like .onion actually was) or not (like .corp is
likely not); from this point on, the WG can clarify by a case-by-case
study what are the underlying issues *concretely* instead of trying to
build a theoretical cathedral that's going nowhere during our lifetime.

If this approach seems sensible, I'm ready to work with a few other
people to make it into, sorry, a third problem statement and a proposal
to walk through this mess from concrete, actual use cases, with what we
already have in the *real world* queue, and figure out the real problems
contextually.

I *know* that a couple of issues were (almost) not verbalized: George
has part of it ("follow the money") and there's the sensitive ICANN-IETF
relationship because nobody on both sides wants to make a decision and
take responsibility for grinding on the other's business.  But let's
leave that aside for a moment otherwise this will drift again away from
technical focus.

I want to ask three questions:

- Can the candidate name be *assigned* by an administrative third-party?
- Can the candidate name be *resolved* using the DNS tree?
- Is the candidate name *colliding* with assigned DNS names?

If we can agree that these three questions are pertinent, and they would
eliminate *some* problematic cases, we would already be left with
*technically relevant cases* to study further.

With each specific case, we'll build up a list of criteria that can fit
the bill, and then we'll be able to evaluate what to do with RFC 6761
with *working assumptions* that avoid intricacies that do not belong to
the technical work of IETF.

At the end of this process we can know:

- what type of requests *matching RFC 6761 procedure* MUST be rejected,
on technical ground (they can be assigned by a third-party and/or they
can be resolved using the DNS tree and/or they are colliding with
assigned DNS names)
- what type of *actual requests* are left to consider, and how many
- what they have in common that can characterize new criteria

It won't address (yet):

- whether to reform or abolish RFC 6761
- what strings can or cannot be accepted
- who gets to choose the strings
- what to do with upcoming requests

But at least I believe the WG will have a clearer picture of the
problem(s) left to address.

==
hk