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

[Juliusz Chroboczek <[e-mail]>]

> Apparently my comment was clear as mud. I meant this:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25

Quote, "YANG-based JSON that describes a Thing", unquote.  61 pages.
Revision 25, and still a draft.  I wish you a lot of fun implementing that.

> Having a public/private zone pair where the public zone is an image of
> the private zone that is constructed following rules, the default rule
> being "don't copy," seems very straightforward to me. It's not clear to
> me in what sense it's brittle.

It's brittle because you have state in the network.  (You know, end-to-end
argument and so on.)

More concretely:

  - what happens when the current hidden master loses an election?  Is the
    state magically transferred?
  - what happens when the current hidden master crashes/is unplugged/is retired?

... let alone the issue of electing the hidden master in the first place,
which I believe Daniel hasn't addressed at all.

> To me, the difference between what you are proposing, Juliusz, and what
> Daniel is proposing, is where the control point is. For you, the control
> point is the device.

That's right.

> For Daniel, the control point is the resolver.

Which resolver?  (I could be wrong, but I don't think that the Homenet
architecture has a central resolver.)

-- Juliusz