During IETF 98, I attended the Homenet Working Group. Homenet is exploring the design of… well, the network of future homes. Not just any home but a home with hundreds of devices, far far more than we have right now (I currently have only 10 devices that are regularly online).
An important consideration for such homes is that they will very probably have more than one connection between the house and the global Internet. You might have a network just for:
- connecting your TV and phone
- managing your power, gas and water
- your children, which would have moderated accessibility
All of these have to co-exist, all of them have to be as painless as possible to configure and run, and, critically, they need to work reliably with one another.
But what about name-based services?
Attending this Working Group, I had to promise myself to be on my best behaviour, because I have been a partisan in a conversation about how to find a name, to hang locally managed things on, for name-based services.
What follows is a personal opinion and I apologize if I offend anyone by mischaracterizing their side of a disagreement, and invite them to contribute their response here on the APNIC blog.
The idea of Homenet, and the multiple networks and network connections it creates, is to do it with as few hands on the tiller as possible: Auto-configuration, and lots of it. However, it has its limitations when it comes to human interaction.
Consider how you currently print over a network. If it’s a local network it should be fairly simple to locate your printer on the network, select it, and print. But imagine your network has four, or more sub-networks. Some print models won’t do auto-discovery over this routing architecture.
To solve this, you need to build out name-based service discovery, which can be agile across the different subnets – printer.homenet is where you’ll find your printer.
But – and it’s a big ‘but’ – those who have been involved in these discussions have tried really hard not to just assume .homenet is ‘the one’. This relates to previous discussions where people used .local and a huge argument ensued over many meetings about ‘who said you could do that’. The end result was the adoption of a process, subject to a memorandum of understanding between the IETF and ICANN, on how to ask for ‘special’ names. A process so fraught, it was shut down.
But, Homenet is knocking at the door. They think they have a sound reason for wanting a top level name, perhaps less ‘technical’ than I might like, but it has been argued with some passion, this is a special-case name, and they want to ask for one. And, it should be human-friendly.
Enter the argument.
I am (as I said) a partisan in this discussion. I don’t like RFC6761, and I don’t like the implications of having a special-pleading mechanism into what ICANN do.
I’d much prefer to see a name like homenet.ARPA selected, which lies under a 2LD, beneath a domain already delegated to the IETF process – the one we use for reverse-address registration among other things.
But, to be fair, I cannot deny the attraction of the name they want, to the community of interest they’ve identified, with one qualifier. It is a rather anglo-centric choice: it presumes the label should be in English. I wonder, if this actually reflects the community well? Should it not maybe be an emoji or, perhaps, we need to have homophones?
Perhaps the goal is not to have .homenet at the top but to understand we need a name, which works no matter where you are. This is the crux of the problem: how do we tell software NOT to look for this name in the global name space. Because that’s not what the global name space is for, it’s to name things, which only lie in the LOCAL name space, outside the system.
There are some real technical issues lurking underneath this problem, which are big, scary arguments between different world views. It’s not going to be solved by ignoring it. Instead, we have people like Brian Trammell from ETH Zurich who are asking the even bigger question: what do we actually want from the name service?
The problem is real and is spread across several groups. It’s going to bounce from HOMENET WG to DNSOPS (it already has, twice) and then back into the IETF open discussion, the IESG, the IAB, the appeals processes; it’s going to be a real popcorn event. Watch this space!
In the view of the IAB, when placing any name in the Special-Use Domain Names registry with the intention that it be used with the DNS protocol, such an entry must be within a domain under the control of the body making the registration. For the IETF, an appropriate domain for such names would be ARPA, as long as those names meet the conditions in RFC3172.
As I stated in my post above, I am a partisan in this debate. I think the IAB made the right decision, and I thank them both for the speed, and the clarity of the declaration.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.