Subject: Re: [DNSOP] I-D Action: draft-michaelson-dnsop-rfc6761-is-closed-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Feb 2016 12:49:41 +1300

Hi George,

>    RFC 6761 [RFC6761] specified mechanisms for reserving a top level
>    name in the DNS.
> 
>    This reversed a prior decision documented by RFC 2860 [RFC2860] to
>    close off mechanisms for name assignment in the IETF, the function
>    being recognized as vesting with ICANN.

That is 100% incorrect. RFC 2860 clause 4.3 states explicitly and for
the exact purpose of *not* closing off assignments in all cases:

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4.

So whatever the technical merits of your proposal, such names and address
blocks remain under the IETF's authority. That doesn't mean the IETF
should blunder around with its eyes closed, but if we want .heffelump.
to be reserved for a technical purpose, we can so decide.

(I am not on the dnsop list so please keep me in cc.)

Regards
    Brian

---

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 13:17:19 +1300

I know it had that clause Brian. I kept the document short. I think the
clause was a sanity clause whose invokation was basically insane. We should
not have formalized a process on it, it should have been something done on
very mature consideration. Instead, we've had a very immature conversation
and now have .onion, the mDNS outcome in .local and the queue of me-too at
the door.

I've discussed this with other people. We don't agree, but there is a sense
that if there is a bar it was set ludicrously low.

So I wrote this document to tease the conversation out.

Without wanting to get pejorative, and understanding there are
sensitivities here, can I ask a very basic question, which you may be able
to answer, but its about *US* not about *YOU* so please don't feel
objectified.

Why is it, in the IETF, we find it so hard collectively to say "we made a
mistake" ?

-George

On Tue, Feb 23, 2016 at 12:49 PM, Brian E Carpenter <
[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Feb 2016 17:18:46 +1300

> that if there is a bar it was set ludicrously low.

In the MoU signed in March 2000, the bar height was undefined, and RFC 6761
doesn't seem to help much with that. If the .onion experience really shows
that this is a problem (and I did not follow the gory details, so I have no
opinion) then it seems to me that the IAB, which owns the relationship with
IANA, needs to take a look and make a recommendation on how to define the
height of the bar.

I don't actually think that RFC 6761 is faulty. It simply doesn't provide
criteria for judging whether a particular technical domain name is important
enough and generic enough to fall in the "domain names for technical uses"
category.

> Why is it, in the IETF, we find it so hard collectively to say "we made a

We make some mistakes that don't matter, because nobody implements something
that turns out to be a bad idea. Some of those get formally rescinded if
anybody cares. Personally, I've done RFC3879, RFC4048, and RFC6563. I haven't
bothered about obsoleting RFC2529 because nobody implemented it except as a
student project.

We make some mistakes that do matter, like anycast 6to4, where I did RFC7526.

Those are personal examples but it's not just me; for example there's
draft-schoenw-opsawg-copspr-historic in progress. The oldest one I found quickly
was RFC1923.

But when something achieves significant deployment, the fact that it was
a mistake becomes embarassing, because it often can't be fixed or retired.

So, I think we do sometimes fix mistakes. Which is of course orthogonal
to whether this particular issue is a mistake.

   Brian

---

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

On 2/22/16 4:17 PM, George Michaelson wrote:
> clause was a sanity clause whose invokation was basically insane. We
> should not have formalized a process on it, it should have been
> something done on very mature consideration. Instead, we've had a very
> immature conversation and now have .onion, the mDNS outcome in .local
> and the queue of me-too at the door.

Before were get off on a tangent how we sealed off our authority to
maintain the technical function of the dns; the delegation of zone cuts
for specialized purposes specifically  in 2860, I'm convinced we did not.

If we had there would be little purpose to the rechartering effort that
led to us discussing 6761 revision today.

> I've discussed this with other people. We don't agree, but there is a
> sense that if there is a bar it was set ludicrously low. 
> 
> sensitivities here, can I ask a very basic question, which you may be
> able to answer, but its about *US* not about *YOU* so please don't feel
> objectified.
> 
> Why is it, in the IETF, we find it so hard collectively to say "we made
> a mistake" ?

Experimentation and mistake is inevitable. If we thought it was hunk
dory, we wouldn't be chartered to review it.  Do I have misgivings about
what has transpired that caused us to arrive at this point? absolutely.

> -George
> 
> On Tue, Feb 23, 2016 at 12:49 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi George,
> 
>     [email-masked] <mailto:[email-masked]>

---

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

I cut an 01 and put the clause in explicitly so its clear the words were
there ab initio. Thanks for pointing 4.3 out, It's worth exposing it. I had
felt like being terce but that wasn't helping.

In the spirit I wrote, I do think 6761 was a mistake but characterizing it
that way has tickled some people. Maybe that was wrong of me.

But you seem to be saying "6761 is not a mistake" ... "except <reasons its
pretty flawed>" which removes the categorical "is not" pretty hard for me.

I got into an architecture-or-names conversation with some people in the
W3C camp and there is a ridiculously strong "no more URI forms" position
there, cemented in. That view of the world is defending a syntactic
structure in the Omnibox and URL bar of browsers against any view that we
have more characters in the ascii palette to play with. Their view can be
summarized as "there will be more <thing>:// for any <thing> not already
defined, if it changes the right hand side of :-> onwards"

I got a lot of "because we wanted all existing code to use this" argument
from Onion advocates, despite some pretty apparent risks built into this:
like, the existing TA structure built into all browsers, which means if a
rogue CA issues a certificate over *.onion, the presumed security of URLs
under it goes out the window, because all browsers older than the ones with
a pinned state are going to accept it.

I got "we cannot use SOCKS" from people. Then others said "we have
instantiated TOR code over SOCKS" which is a pretty big WAT moment for me:
a and not-a in the same argument from the same side, is very confusing.

You say "its with the IAB" but I am looking at that middle letter A for
ARCHITECTURE and wondering.. who on the IAB has any sense of an
architecture except the architecture of pragmatism?

We have an entry condition of the CA community demanding a process outcome
to permit the Onion certificate to be issued. Where is the wider public
review of that process? I guess thats out of scope but the feeling they
operate in a mode which is not very transparent is strong.

And then we have the queue of other 'cute tricks in names' people, pressing
all my buttons over what a name system is, what domain-names,
hierarchically scoped names are.

Scary.

I don't think having a process like 6761 open in this situation is healthy
for us.

-George

On 23 February 2016 at 17:18, Brian E Carpenter <[email-masked]
> wrote:

> should
> sense
> able