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 protected] > wrote: > On 23/02/2016 13:17, George Michaelson wrote: > > 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. > > 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. > > > 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" ? > > 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 > > > > > -George > > > > On Tue, Feb 23, 2016 at 12:49 PM, Brian E Carpenter < > > [email protected]> wrote: > > > >> 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 > >> > >> _______________________________________________ > >> DNSOP mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dnsop > >> > > >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
