Re: [homenet] Simple Homenet Naming Architecture...

Markus Stenberg <markus.stenberg@iki.fi> Tue, 14 March 2017 08:49 UTC

Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <BEF262EC-51EB-464B-AD9E-0CCF25ECD48F@fugue.com>
Date: Tue, 14 Mar 2017 10:49:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <80BCEE0D-BF31-45F1-A21C-0FE3A24CB492@iki.fi>
References: <148944217975.20370.12525433504127407949@ietfa.amsl.com> <BEF262EC-51EB-464B-AD9E-0CCF25ECD48F@fugue.com>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/183_92OEgVd_Babo0sb_3dFPK38>
Cc: HOMENET <homenet@ietf.org>
Subject: Re: [homenet] Simple Homenet Naming Architecture...
Precedence: list

On 13 Mar 2017, at 23.58, Ted Lemon <mellon@fugue.com> wrote:
> Daniel Migault and I have been working on the Simple Homenet Naming Architecture.   I’ve posted a -00 that I hope we can discuss in Chicago.

S1.1: The assumption in UI is false. The visible services (at least in the legacy browse mode, e.g. ‘flat list’, do not need to have topology information visible to the user; in browse mode, full domain is usually shown).

S3.3: Why MUST filter out globals? I do not see the reason, and if I do not, casual reader might not either. If it is just an opinion, it could be SHOULD perhaps.

The subsection lists 3 functions (querying, aggregating, relaying) but says there are only two types of proxies. I am slightly confused.

My reading (which you do not state explicitly) is that you advocate a solution where you have ‘aggregating proxy’ which asks for results from multiple links, and combines them, handling uniqueness of responses; however, the devices themselves will not even know they are ‘computer 72’ and not ‘computer.local’ which they advertise on the link. This gets quite awkward as devices come and go if they do not locally know their name, unless the aggregating function is fully stateful and robust (= mappings stay constant until end of time) and it can somehow determine that moved node (computer.local which moved from link A to link B to new name computer-2.local as there was computer.local already on the link B) is still same.

In my experimentation in 2013, somewhat better working design seemed to be forcing the aggregated name mappings to stay unique by essentially forcing devices to rename themselves until the computer.local thinks it is actually computer 72.local (or whatever) which is network-wide unique and then when it moves its node name part stays same.

Anyway, it looks like a good start, at least no mention of dnssec or crazy delegation to random third party by default. 

Cheers,

-Markus

[homenet] Simple Homenet Naming Architecture... Ted Lemon
Re: [homenet] Simple Homenet Naming Architecture.… Ted Lemon
Re: [homenet] Simple Homenet Naming Architecture.… Markus Stenberg
Re: [homenet] Simple Homenet Naming Architecture.… Ted Lemon