Re: [homenet] (no subject)

[Ted Lemon]

You said that having state in the homenet makes it brittle.   That implies
that you think a stateless homenet will be less brittle, no?

On Tue, Jul 24, 2018 at 4:34 AM, Juliusz Chroboczek  wrote:

> > Juliusz is saying that he wants a nearly stateless homenet;
>
> No, I'm not.
>
> > for him, putting the public/primary functional block in the cloud makes
> > sense
>
> No, it doesn't.
>
> Ted, please don't put words into my mouth.  It's unpleasant, and it's
> disrespectful.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Juliusz Chroboczek]

> Juliusz is saying that he wants a nearly stateless homenet;

No, I'm not.

> for him, putting the public/primary functional block in the cloud makes
> sense

No, it doesn't.

Ted, please don't put words into my mouth.  It's unpleasant, and it's
disrespectful.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Ted Lemon]

Sure, it *could*, but it's probably easier to implement it as a
split-horizon DNS server that only talks to the homenet.

On Tue, Jul 24, 2018 at 12:31 AM, Tim Wicinski  wrote:

> Instead of calling it a "DNS Server" perhaps call it the "declarative data
> store"?  it could be a git repo,
>
> tim
>
> On Mon, Jul 23, 2018 at 10:43 PM, Ted Lemon  wrote:
>
>> The DNS server in the cloud doesn't have to answer queries.   Indeed, it
>> probably shouldn't.   It's really just a backing store.   The
>> public/private primary with selective publication is just a functional
>> block—you can put it where it makes the most sense.   Juliusz is saying
>> that he wants a nearly stateless homenet; for him, putting the
>> public/primary functional block in the cloud makes sense because it keeps
>> his homenet stateless.   I would not want that configuration because it
>> exposes the internals of my network to the cloud provider (unless it's also
>> encrypted, but then you have a keying problem).
>>
>> On Mon, Jul 23, 2018 at 9:02 PM, Michael Thomas  wrote:
>>
>>> On 07/23/2018 05:45 PM, STARK, BARBARA H wrote:
>>>
 You're concerned with the homenet losing state when the master is
>> unplugged.   By having the master in the cloud, this problem is 
>> eliminated.
>>
> I can't speak for Juliusz, but my first question was "what if i don't
> want it in the cloud"? For one thing, what if it's a cloudless day?
>
 I was starting to accept the idea that selecting a subset of my devices
 to exist in global DNS. But absolutely, positively, not all. Any design I
 could buy into will *not* push all my DNS into the cloud.

>>>
>>> As usual i'm probably behind, but I kind of thought this was more about
>>> provisioning/configs. The way I've thought
>>> about this is that where I decide is the ultimate repository for truth
>>> for my configs is really a deeply personal
>>> decision. The easy case is when i delegate it to "the cloud" since it
>>> then becomes somebody else's $DAYJOB to
>>> figure out how to back it up, etc. But if I want to keep things local --
>>> for whatever reason, including tin foil hats --
>>> i'd really like my homenet to have the property that i can take one
>>> router and throw it in the trash, and plug in
>>> another, and with minimal fuss it takes over for the old one.
>>>
>>> For naming, that implies that i want to distribute the naming database
>>> such that there isn't a single point of failure.
>>> While this isn't exactly new territory, it is in the context of my home
>>> networking. Better would be to use already
>>> standardized mechanisms so that everybody's sanity is preserved, if only
>>> a little bit.
>>>
>>> Mike
>>>
>>>
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Tim Wicinski]

Instead of calling it a "DNS Server" perhaps call it the "declarative data
store"?  it could be a git repo,

tim

On Mon, Jul 23, 2018 at 10:43 PM, Ted Lemon  wrote:

> The DNS server in the cloud doesn't have to answer queries.   Indeed, it
> probably shouldn't.   It's really just a backing store.   The
> public/private primary with selective publication is just a functional
> block—you can put it where it makes the most sense.   Juliusz is saying
> that he wants a nearly stateless homenet; for him, putting the
> public/primary functional block in the cloud makes sense because it keeps
> his homenet stateless.   I would not want that configuration because it
> exposes the internals of my network to the cloud provider (unless it's also
> encrypted, but then you have a keying problem).
>
> On Mon, Jul 23, 2018 at 9:02 PM, Michael Thomas  wrote:
>
>> On 07/23/2018 05:45 PM, STARK, BARBARA H wrote:
>>
>>> You're concerned with the homenet losing state when the master is
> unplugged.   By having the master in the cloud, this problem is 
> eliminated.
>
 I can't speak for Juliusz, but my first question was "what if i don't
 want it in the cloud"? For one thing, what if it's a cloudless day?

>>> I was starting to accept the idea that selecting a subset of my devices
>>> to exist in global DNS. But absolutely, positively, not all. Any design I
>>> could buy into will *not* push all my DNS into the cloud.
>>>
>>
>> As usual i'm probably behind, but I kind of thought this was more about
>> provisioning/configs. The way I've thought
>> about this is that where I decide is the ultimate repository for truth
>> for my configs is really a deeply personal
>> decision. The easy case is when i delegate it to "the cloud" since it
>> then becomes somebody else's $DAYJOB to
>> figure out how to back it up, etc. But if I want to keep things local --
>> for whatever reason, including tin foil hats --
>> i'd really like my homenet to have the property that i can take one
>> router and throw it in the trash, and plug in
>> another, and with minimal fuss it takes over for the old one.
>>
>> For naming, that implies that i want to distribute the naming database
>> such that there isn't a single point of failure.
>> While this isn't exactly new territory, it is in the context of my home
>> networking. Better would be to use already
>> standardized mechanisms so that everybody's sanity is preserved, if only
>> a little bit.
>>
>> Mike
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Ted Lemon]

The DNS server in the cloud doesn't have to answer queries.   Indeed, it
probably shouldn't.   It's really just a backing store.   The
public/private primary with selective publication is just a functional
block—you can put it where it makes the most sense.   Juliusz is saying
that he wants a nearly stateless homenet; for him, putting the
public/primary functional block in the cloud makes sense because it keeps
his homenet stateless.   I would not want that configuration because it
exposes the internals of my network to the cloud provider (unless it's also
encrypted, but then you have a keying problem).

On Mon, Jul 23, 2018 at 9:02 PM, Michael Thomas  wrote:

> On 07/23/2018 05:45 PM, STARK, BARBARA H wrote:
>
>> You're concerned with the homenet losing state when the master is
 unplugged.   By having the master in the cloud, this problem is eliminated.

>>> I can't speak for Juliusz, but my first question was "what if i don't
>>> want it in the cloud"? For one thing, what if it's a cloudless day?
>>>
>> I was starting to accept the idea that selecting a subset of my devices
>> to exist in global DNS. But absolutely, positively, not all. Any design I
>> could buy into will *not* push all my DNS into the cloud.
>>
>
> As usual i'm probably behind, but I kind of thought this was more about
> provisioning/configs. The way I've thought
> about this is that where I decide is the ultimate repository for truth for
> my configs is really a deeply personal
> decision. The easy case is when i delegate it to "the cloud" since it then
> becomes somebody else's $DAYJOB to
> figure out how to back it up, etc. But if I want to keep things local --
> for whatever reason, including tin foil hats --
> i'd really like my homenet to have the property that i can take one router
> and throw it in the trash, and plug in
> another, and with minimal fuss it takes over for the old one.
>
> For naming, that implies that i want to distribute the naming database
> such that there isn't a single point of failure.
> While this isn't exactly new territory, it is in the context of my home
> networking. Better would be to use already
> standardized mechanisms so that everybody's sanity is preserved, if only a
> little bit.
>
> Mike
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Michael Thomas]

On 07/23/2018 05:45 PM, STARK, BARBARA H wrote:

You're concerned with the homenet losing state when the master is unplugged.   
By having the master in the cloud, this problem is eliminated.

I can't speak for Juliusz, but my first question was "what if i don't want it in the 
cloud"? For one thing, what if it's a cloudless day?

I was starting to accept the idea that selecting a subset of my devices to 
exist in global DNS. But absolutely, positively, not all. Any design I could 
buy into will *not* push all my DNS into the cloud.


As usual i'm probably behind, but I kind of thought this was more about 
provisioning/configs. The way I've thought
about this is that where I decide is the ultimate repository for truth 
for my configs is really a deeply personal
decision. The easy case is when i delegate it to "the cloud" since it 
then becomes somebody else's $DAYJOB to
figure out how to back it up, etc. But if I want to keep things local -- 
for whatever reason, including tin foil hats --
i'd really like my homenet to have the property that i can take one 
router and throw it in the trash, and plug in

another, and with minimal fuss it takes over for the old one.

For naming, that implies that i want to distribute the naming database 
such that there isn't a single point of failure.
While this isn't exactly new territory, it is in the context of my home 
networking. Better would be to use already
standardized mechanisms so that everybody's sanity is preserved, if only 
a little bit.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[STARK, BARBARA H]

> > You're concerned with the homenet losing state when the master is 
> > unplugged.   By having the master in the cloud, this problem is eliminated.

> I can't speak for Juliusz, but my first question was "what if i don't want it 
> in the cloud"? For one thing, what if it's a cloudless day?

I was starting to accept the idea that selecting a subset of my devices to 
exist in global DNS. But absolutely, positively, not all. Any design I could 
buy into will *not* push all my DNS into the cloud.
Barbara

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Michael Thomas]

On 07/23/2018 03:36 PM, Ted Lemon wrote:
On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek > wrote:

What?


You're concerned with the homenet losing state when the master is 
unplugged.   By having the master in the cloud, this problem is 
eliminated.


I can't speak for Juliusz, but my first question was "what if i don't 
want it in the cloud"? For one thing, what if it's a cloudless day?


Mike
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Ted Lemon]

On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek  wrote:
> What?

You're concerned with the homenet losing state when the master is unplugged.   
By having the master in the cloud, this problem is eliminated.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Juliusz Chroboczek]

> if the homenet loses its memory, it can simply refresh it from the cloud.

What?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Ted Lemon]

On Mon, Jul 23, 2018 at 4:08 PM, Juliusz Chroboczek  wrote:

>  whereas Daniel's draft only allows me to publish my address
> if I'm in my Homenet.
>

One of the reasons I was hassling Daniel at the mic about updating his
draft based on implementation experience is that I think it's hard to read
the document and get a clear sense of what is being described.

That said, what is being described is a building block, not a system.   The
hidden primary is a building block.   You mention in another message that a
stateful primary is brittle, because there is no permanent authority on a
homenet.   You are actually agreeing with Daniel: the reason to have the
state somewhere other than the homenet is that it can be managed by someone
who maintains it; then if the homenet loses its memory, it can simply
refresh it from the cloud.

How to update your DNS when you aren't on the homenet is a separate issue.
 One way to do it would be to always be connected to the homenet over a
VPN; another would be for the homenet to have a global name and just do it
the usual way; this global name could be set up in much the same way that
you are proposing to set up individual hostnames: not a delegation from a
TLD, but a delegation from a service provider.

That said, the use case for what you are describing is a bit beyond the
pale for a typical end user.   They just want to be able to reach their
printer or their home automation system.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet