Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

[Juliusz Chroboczek <[e-mail]>]

> The main idea is that the CPE builds the zone for the whole home network.

Thanks for the clarification.

Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that
right now I'm strongly opposed to this protocol.  I hold no opinion yet on
whether proxying is necessary (although I hope it isn't), but I am strongly
opposed to binding the DNS proxy role with the CPE at the protocol level.
(This does not mean that the DNS proxy cannot be colocated with the CPE,
only that I find a protocol that mandates this kind of colocation unacceptable.)

> I am rephrasing your use case to make sure we have the same in mind. Please
> clarify if we do not agree on the use case. You consider is a web server in
> the home network, that you want to be reachable from the Internet. In order to
> do that you buy a specific domain name www.homenet.com. The domain is hosted
> on a Public Authoritative Server, you edit the zone, add the IP address of
> your server.

Oh, nothing that geeky.  I copy my vacation photographs onto my NAS.
I click the "share over the Internet" button on the NAS's web interface.
The NAS performs DynDNS registration, I get a link that I can copy-paste
into an e-mail to my mom: "Mom, the vacation photographs are on
http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password
is 1234."  I've avoided putting my private photographs on Google's
servers -- and we're changing the world.

I click on the "share over the internet" button on my stereo's web
interface.  The stereo performs DynDNS registration, I get a link that
I can copy-paste.  "Daniel, the song you found so funny at my place last
night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music,
the password is 1234".  I've avoided sending 20MB of Ukrainian R'n'B over
SMTP -- and we're changing the world.

I'm at the train station.  There's a strike on.  I'm playing Civilisation
on my laptop in an internet cafe.  I click the "Invite over the Internet"
button.  Civilisation performs DynDNS registration, I get a link which
I can copy-paste.  "Daniel, I'm bored, join me for a game of Civilisation,
link is civ://www.user-fe83-paris-13.dyndns.example.com, password is
1234", and now I can wholeheartedly support the cheminot's strike -- we're
changing the world again.

>     1) It is not scalable in term of configuration: if you have a single
> server, you can edit the zone. If you have 100 devices (which is not much) you
> will not be able to do it especially if you IP prefix changes every day.

Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
dynamic updates to be dependent on my CPE, which is buggy (it was provided
by the major competitor of your employer) and isn't available at the
internet cafe.

>     2) It is not scalable in term of software installation: every registrar
> have its own API for configuring the zone.

Then why not standardise a registration API?

> Furthermore, if you suppose all registrar agree to have a unique way to
> do so, -- suppose nsupdate -- all devices will have to implement this
> protocol. For most devices this may be not a problem, however, for all
> devices like sensors having to perform nsupdate every day, may impact
> their battery life time for nothing.

If you really believe that proxying is necessary (and I'd like actual
figures to support this claim -- how many devices do you have in your home
that cannot afford the cost of one registration every few hours?), then
there's nothing preventing a DNS proxy from using the standardised
registration protocol on behalf of its clients.  Then clients can choose
whether to go through the proxy, and users can choose whether use the
ISP-provided proxy (co-located with the CPE) or a third-party proxy that
happens to work.

>     3) It is not automatic and flexible: A new device that is in your network
> cannot have a name, as an admin needs to register its name in the zone 
> myhomenet.com, or provide the credential for it to all new devices.

That's what we have HNCP for -- for distributing random data to all devices.

>     4) It is not scalable in term of zone management and bandwidth: Suppose
> you have n devices in the home network and a renumbering occurs. All these n
> devices will contact the Public Authoritative Server that may be miles away
> from your home network.

I've got 100 devices.  I renumber.  Each device sends 500 bytes of
registration data.  My monthly Internet bill has just increased by 50 kB.

>     5) it exposes your homenet to IP disruption. Suppose your ISP has a
> connectivity issue, even a node in your home network will not be able to
> contact your web server as the DNS(SEC) resolution is not possible. 

But my nodes are still running mDNS/zeroconf, right?  Or are you deprecating
that?

-- Juliusz