On Fri, May 08, 2015 at 08:10:41PM -0700, Paul Hoffman wrote: > > - Will the IETF require some specific metrics for RFC 6761 reservations? > > - If yes, what are those metrics? > > - If no, who makes the non-specific decision?
Increasingly it strikes me that RFC 6761 is trying to do too much. It was, as we all know, created as a _post hoc_ rule to permit the creation of local, on which Apple squatted to create Bonjour. That was one particular use of a namespace: the namespace amounts to a protocol-shifting mechanism. We can expect to see this again (and indeed, several of the names that are in the p2pnames draft are effectively in this class). In order to create that set of rules, however, the special use names registry came about. That registry includes all sorts of other special-use names that are in fact reserved for _policy_ reasons. For instance, example, test, and invalid are there because of the policy of needing certain names for testing, documentation, and so on. Similar arguments can be made about the RFC1918 addresses in arpa: these are special only because of a different policy decision to reserve chunks of v4 space for local use. The interesting case is localhost, which I think might have elements of each of these properties, though because of the binding to the 127.0.0 network you might be able to argue that the policy is actually elsewhere. It seems to me that making new reservations solely on _policy_ grounds is overstepping our role, because we actually gave that management function away to someone else many years ago. But if there are additional protocol-shift registrations, it would be appropriate to do that. This makes me think that what we ought to offer ICANN is a mechanism to make insertions into the special-names registry by different criteria than the protocol-shift cases. The latter all fit neatly into 6761's "7 questions", but policy-based ones sort of don't. Anyway, that's a suggestion. A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
