Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek <[e-mail]>]

> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.

I am not speaking about discovery within the Homenet.  I am speaking about
exporting names into the global DNS, which is what Daniel's draft is about.

> It's certainly true that we could use an HTTPS-based protocol for setting up
> delegations for the forward mapping zone. This makes a great deal of sense,

Good.

> The reverse mapping zone has to be delegated by the ISP, so we might as
> well do it in a prefix delegation transaction.

I'm not following your reasoning here -- why does the zone being tied to
the ISP imply that we must use a more complex protocol?

> So if you are advocating this second thing, that makes sense, and we should
> definitely talk about whether it makes sense to do it this way.

Let's.

> Also, think of the privacy implications if all of the services on the
> homenet had to be discovered from a shared zone like dyndns.org.

Quite the opposite.  In the trivial update protocol, the update is
end-to-end, encrypted, and only the host and the DNS provider see the
data.  Every Homenet, every host, heck, even every application can use
a different DNS provider, and each DNS provider only sees the data that
was explicitly sent to it.

In Daniel's protocol, the data goes from host to hidden primary to DNS
provider.  The hidden primary is probably controlled by the ISP, which is
convenient if you happen to be a privacy-violating ISP.

-- Juliusz