Subject: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 12:14:39 +1300

I've just lodged

https://datatracker.ietf.org/doc/draft-michaelson-dnsop-rfc6761-is-closed/

I am requesting a slot in the DNSOP WG session at ietf95 B.A. to discuss
this.

cheers

-George

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Feb 2016 20:22:30 -0500

If this draft comes from an individual, then I think it is best left dormant until all the groups and initiatives about resolving these 6761 issues have progressed a bit further.

Paul

Sent from my iPhone

> On Feb 22, 2016, at 18:14, George Michaelson <[email-masked]> wrote:
> 
> I've just lodged 
> 
> I am requesting a slot in the DNSOP WG session at ietf95 B.A. to discuss this.
> 
> cheers
> 
> -George
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 14:42:01 +1300

I could agree, but I think the (plausible?) proposal to shut it down,
stands alongside the proposals to seek to amend. I personally would prefer
they were discussed at the same time, because otherwise you have led the
world to believe there is a process to ameliorate and exclude the
shut-it-down option.

Really, Its about the conversation. I don't feel like I stand in a caucus
with very many members.

-G

On Tue, Feb 23, 2016 at 2:22 PM, Paul Wouters <[email-masked]> wrote:

> If this draft comes from an individual, then I think it is best left
> dormant until all the groups and initiatives about resolving these 6761
> issues have progressed a bit further.
>
> Paul
>
> Sent from my iPhone
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Feb 2016 20:48:58 -0500 (EST)

On Tue, 23 Feb 2016, George Michaelson wrote:

> I could agree, but I think the (plausible?) proposal to shut it down, stands
> alongside the proposals to seek to amend. I personally would prefer they
> were discussed at the same time, because otherwise you have led the world to
> believe there is a process to ameliorate and exclude the shut-it-down
> option.

I seem to remember that the working group already put all 6761 related
requests for TLDs on hold. So new TLDs cannot be requested to be reserved
via 6761 anyway. I don't think a further RFC is needed to formalise
this. Although that can be discussed on the dnsop list of course.

Paul

---

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 14:55:15 +1300

> this. Although that can be discussed on the dnsop list of course.

Respectfully, I don't agree. the current shut-down is an ad-hoc decision.
It needs the formalism to close it permanently, if we expect to stop people
coming to the door. If we have a sense at some stage the door is
re-opening, we can expect the queue not only to be maintained, but to grow.

I think the proper place for the queue is in another venue (ICANN) and
their lack of a proper technical justification channel independently of our
process is a problem, but its a problem in their space, not in our space.

Equally, if a proposal like the ALT namespace was secured, the
special-names registry would be superceded by the ALT registry, which
operated on a completely different basis with different consequences and
costs. I don't think the special-use names registry should remain open
on-hold, if we secure ALT.

So I think a distinct formalism which says "we made a mistake: we don't do
this" has merit.

This is basically what I'd expect to say on slideware in the meeting. But
we can do it here too.

-george

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Feb 2016 21:05:33 -0500 (EST)

On Tue, 23 Feb 2016, George Michaelson wrote:

> Respectfully, I don't agree. the current shut-down is an ad-hoc decision. It
> needs the formalism to close it permanently

We first need these processes to produce results before we decide
whether or not to close that door permanently.

> I think the proper place for the queue is in another venue (ICANN) and their
> lack of a proper technical justification channel independently of our

And the intersection of that space is also working on updating the 6761
situation. The dnsop
working group, the TEG/TLG, the IAB (via the iniip-discuss list), the
GNSO, etc. etc. [Note: I am one of the two TEG/TLG liaisons of the IETF
to the ICANN board. Warren Kumari is the other one]

> Equally, if a proposal like the ALT namespace was secured, the special-names
> registry would be superceded by the ALT registry, which operated on a
> completely different basis with different consequences and costs. I don't
> think the special-use names registry should remain open on-hold, if we
> secure ALT.

The .alt is also not going to get secured before these talks have
proceeded further with all stakeholders involved. So I don't think there
is a rush in formally closing the frozen 6761 procedure. In fact, it
could hinder the current process by the IETF forcing a decision on its
own.

> This is basically what I'd expect to say on slideware in the meeting. But we
> can do it here too.

Face to face time is rare. It also does not include everyone that's on
the list. So where possible, discussion on the lists is always preferred.

Paul

---

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 15:21:34 +1300

> the list. So where possible, discussion on the lists is always preferred.

A good bar. A high bar. A high bar, which I don't think the "design team"
output can meet because I've checked the archives, to match my memory, and
substantive discussion on the qualities of the idea of having a registry
are few: there are nits on the words of the revision, but we've yet to
actually broach "do we want to do this" in any real form.

So consider the door open on that discussion:

Folks: Do we *really* want to do this? Do we really *want* to revise
RFC6761? Can we talk about this a bit?

Me? I don't want to do this. I want a process that is so rarely invoked,
you have to be a lot taller to get on the ride, than at present. I want a
substantive IETF-wide technically understood reason that is breaking
architecture, avoiding URI methods, requiring code, that we all understand.

And certainly not "because a lot of users now depend on it, because we
squatted"

-G

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Feb 2016 20:07:57 -0800

On 2/22/16 6:21 PM, George Michaelson wrote:
> 
> 
> On Tue, Feb 23, 2016 at 3:05 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> A good bar. A high bar. A high bar, which I don't think the "design
> team" output can meet because I've checked the archives, to match my
> memory, and substantive discussion on the qualities of the idea of
> having a registry are few: there are nits on the words of the revision,
> but we've yet to actually broach "do we want to do this" in any real form.
> 
> you have to be a lot taller to get on the ride, than at present. I want
> a substantive IETF-wide technically understood reason that is breaking

The part I like about your proposed position is that it's unequivical.

> And certainly not "because a lot of users now depend on it, because we

Oddly I'm not enthused by this as a reason for existing or future 6761
registration reuest, technical merit or necessity on the other hand is
not carte blanche to employ 6761 or at least is doesn't seem to be and
matters of taste are hard to fence in with objective criteria.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 23 Feb 2016 09:01:42 -0500

> RFC6761? Can we talk about this a bit?

RFC6761 in the context of root zone was a huge MISTAKE,
please push document though.
We have wasted enough time on 6761 fallouts, it is time for the misery to
end.

> George, thanks for writing this up
I support this document and want to see the mistake named RFC6761 erased

We should have something to point squatters to and that is where ".alt"
fits in.

  Olafur

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2016 09:51:20 -0500 (EST)

> We have wasted enough time on 6761 fallouts, it is time for the misery to end. 

I dont think anyone disagrees. But with various parties working on the
fix, the question is should dnsop push the kill switch right now? We
have the design team, the IAB, ICANN, etc all looking at resolving this,
and 6761 name processing is currently on hold.

> We should have something to point squatters to and that is where ".alt" fits in.

But proceeding with that is also on hold because it would actually use
the 6761 process to get passed?

Paul

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 23 Feb 2016 10:53:03 -0500

George,

Before this discussion goes too much further:

The design team was asked to produce a problem statement. They produced a -00 draft, and we expect a -01 based on what they've heard in Yokohama and on the list imminently. The -00 is at http://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/.

To your request for time for your draft: we're not sure yet where it fits but the chairs have requested two sessions on the Buenos Aires agenda, so we can have a dedicated slot for the attempt to move forward on special use names.

To your question:

On Feb 22, 2016, at 9:21 PM, George Michaelson <[email-masked]> wrote:
> Folks: Do we *really* want to do this? Do we really *want* to revise RFC6761? Can we talk about this a bit?

There's been no decision taken that we do. We asked for a problem statement first, in some hope that we wouldn't leap (again?) to solutions without one. It seemed like a good idea to have a list of the reasons why people think the special use names registry is useful, or not.

If you think the draft is missing important pieces of that list, please (please!!) say so.

> Me? I don't want to do this. I want a process that is so rarely invoked, you have to be a lot taller to get on the ride, than at present. I want a substantive IETF-wide technically understood reason that is breaking architecture, avoiding URI methods, requiring code, that we all understand. 

IIUC you're arguing that there are inherent harms in having a process that's "too easy" in your view. This is valid input for the problem statement draft. 

More generally, "substantive IETF-wide reason" and discussion on the broader topic is the conversation that the IAB is trying to encourage with inip-discuss and ARCING, as there's more to the architecture of naming and the use of domain names in the internet than the DNS protocol.

Drafts you might find of interest include:
https://datatracker.ietf.org/doc/draft-lewis-domain-names/
https://datatracker.ietf.org/doc/draft-hardie-resolution-contexts/

best,
Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 23 Feb 2016 10:56:33 -0500

> the 6761 process to get passed?

Yes.

Suzanne

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2016 10:57:57 -0500 (EST)

> To your request for time for your draft: we're not sure yet where it fits but the chairs have requested two sessions on the Buenos Aires agenda, so we can have a dedicated slot for the attempt to m…

That's for doing that! I really appreciate the effort to prevent 6761
from taking up all dnsop time!

Paul

---

From: Geoff Huston <[email-masked]>
Date: Wed, 24 Feb 2016 04:47:18 +1100

> On 24 Feb 2016, at 1:51 AM, Paul Wouters <[email-masked]> wrote:
> 
> fix, the question is should dnsop push the kill switch right now?

yes it should!

> We

And we need all these folk to press a kill switch? Really? Truly? 

Do we have such a pressing need to engage that many folk to collectively
wallow in the misery of the consequences of our poor decisions of the past?

Kill it! It was a hideous mistake!

Please publish draft-michaelson-dnsop-rfc6761-is-closed and be done with this
collective indulgence of dissection of our inglorious past!

nuff said.

Geoff