Hi, (no hats)
I had honestly expected the work on the homenet naming architecture to include a discussion of constraints on the syntax and other characteristics of the names to be used. The default set for the homenet namespace in RFC 7788 strikes me as a risky recommendation from a purely operational perspective. It's been surmised now for years that ".home" is widely used in local DNS configurations, based on the so-called "name collision" work commissioned by ICANN, and it's hard to see how collisions between overlapping local uses of the same names is preferable in any way to collisions between the global default namespace and local uses. There's no reason to assume that homenet use of ".home" is compatible with pre-existing uses. Name collisions within one local scope, or multiple overlapping local scopes, seem to me to be dangerous in exactly the same ways as ambiguity between the "public namespace" and a local one would be. Even a special use registry entry can't reasonably be expected to have a big impact on the other uses of ".home" that the name collision work surmised to be already occurring in the operational internet-- or the collisions that could occur if the homenet recommendation is widely used. Using ".home" for homenets is a bad idea, and would have been a bad idea even if there was a special use registry entry for it. Suzanne On Apr 23, 2016, at 10:58 PM, Ted Lemon <[email protected]> wrote: > The Special-Use Top-Level Internet Names Problem Statement draft > (https://tools.ietf.org/html/draft-tldr-sutld-ps-00) references the ICANN > document that talks about .home (I don't know the URL off the top of my > head). Like Suzanne, I'm pretty embarrassed that I didn't catch this. The > RFC only references ".home" once, and says nothing about how it is handled, > as would be needed for the RFC 6761 process, and of course there's nothing > about .home in the IANA considerations. I will be adding this RFC to the > list of documents in the tldr draft, because what happened here is definitely > "a problem." > > FWIW, I presented a homenet naming architecture document in the homenet > working group that talks about how this actually ought to be done > (https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00). I > am fairly sure that the appearance of ".home" as a default setting in the > HNCP draft was an oversight on the part of the authors--the working group had > been using ".home" as a shorthand for "the special-use top-level internet > name that we'll use for name resolution in home networks that don't have > global names delegated to them," which as you can see is a bit of a mouthful. > > Bottom line: this is not actually the intended way things should work for > naming in homenets, and a lot of people missed it. Sigh. > > > On Sat, Apr 23, 2016 at 9:14 PM, John Levine <[email protected]> wrote: > >sounds like there could be trouble with that > > > >https://icannwiki.com/.home > > > >based on the applicants currently investing in acquiring that TLD. > > There's a bunch of applicants for .HOME, .CORP. and .MAIL. I gather > that ICANN has decided not to delegate any of them due to collisions > with existing use in the wild. (For .home, there's a lot of random > little routers using it, unrelated to new RFC 7788 uses.) > > There was some discussion in the IETF of adding those three names to > the RFC 6761 registry, but it didn't go anywhere, largely (in my > opinion) due to lobbying by one of the .home applicants. > > R's, > John > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
