On 2/22/16 4:17 PM, 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.
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. > > 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" ? 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 protected] <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dnsop > > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
