Re: [homenet] Naming requirements

[Ted Lemon <[e-mail]>]

I'm going to blame this on jet lag.   Sorry, Juliusz.   I meant Juliusz,
not Julian.

On Mon, Jul 17, 2017 at 6:03 PM, Ted Lemon <[e-mail]> wrote:

> Julian asked me to write this up, so I'm sending a note with what I think
> the requirements are:
>
> 1. It should be possible for hosts on the homenet to resolve names
> 2. It should be possible that if the homenet is multi-homed, a host that
> is capable of supporting provisioning domains (RFC7556) is able to treat a
> particular ISP's prefix and resolvers as being in a different provisioning
> domain than another ISP's prefix and resolvers.
> 3. For hosts that do not support multiple provisioning domains, it should
> be the case that the homenet only presents a single provisioning domain to
> them (we can treat the homenet provisioning domain and one of the ISP
> provisioning domains as a single provisioning domain for the sake of this
> statement).
> 4. It should be possible for hosts on any link on the homenet to discover
> services on that or any other link on the homenet
> 5. Full support for existing uses of service discovery (e.g., Apple's
> Sleep Proxy) should exist
> 6. It should be possible for an HNR that has greater capabilities (e.g.
> the advanced homenet naming architecture) to be elected as the default
> resolver for the homenet, so that all hosts on the homenet have access to
> the improved features of that HNR
> 7. Not all HNRs should be required to support the advanced homenet naming
> architecture.
> 8. Possibly it should be possible to have a low-cost HNR that cannot act
> as an HNR in support of the simple homenet naming architecture without
> there being a fully-capable HNR on the network (IOW, an HNR that supports
> Discovery Relay but not Discovery Proxy).
>
> I don't know that the entire working group agrees on this set of
> requirements, but it's my best attempt to dump my internal state on the
> topic.   It's quite possible that I've failed to report one of these
> internalized requirements, of course.
>