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 < > brian.e.carpen...@gmail.com> 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 >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
