Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

[Juliusz Chroboczek <[e-mail]>]

> I have some other fairly serious nits about this document, but I believe
> that the argument above is sufficient.  I am opposed to adoption at this
> stage, but look forward to reconsidering once dnssd has had a serious look
> at the protocols.

I didn't want the point of the previous mail to be diluted by a list of
nits, so I've kept it short.  Here are just some of the more serious
issues I've noticed when doing a first read of the document.

Please be aware that even if these issues were resolved, I would not
necessarily support adoption.

> 1.  Introduction

> o  Provisioning of a domain name under which names can be published
>    and services advertised

This document doesn't mention HNCP's mechanisms to do that.  Either this
document updates HNCP to not provision a domain name, in which case it
should say so, or it relies on HNCP's mechanism, in which case it should
say so.

> 1.  Some names may be published in a broader scope than others.

This implies that the local and global publication mechanism are the same,
which does not reflect WG consensus as far as I am aware.  I've already
mentioned on this list that I believe that local and global naming should
use different mechanisms -- by merging the two, you're converting two
tractable problems into one that is difficult.

> 6.  Homenet explicitly supports multihoming--connecting to more than
>     one Internet Service Provider--and therefore support for multiple
>     provisioning domains [6] is required to deal with situations
>     where the DNS may give a different answer depending on whether
>     caching resolvers at one ISP or another are queried.

This implies that mpvd is the preferred mechanism.  As far as I know, this
does not reflect WG consensus.

> 3.1.  Configuring Resolvers

> Hosts on the homenet receive a set of resolver IP addresses using
> either DHCP or RA.  IPv4-only hosts will receive IPv4 addresses of
> resolvers, if available, over DHCP.  IPv6-only hosts will receive
> resolver IPv6 addresses using either stateful (if available) or
> stateless DHCPv6, or through the domain name option in router
> advertisements.  All homenet routers provide resolver information
> using both stateless DHCPv6 and RA; support for stateful DHCPv6 and
> DHCPv4 is optional, however if either service is offered, resolver
> addresses will be provided using that mechanism as well.

Either this restates the requirements in RFC 7788, in which case it must
say so, or it updates RFC 7788, in which case it must say in what way.

> every HNR is required to provide name resolution service.

I do not believe that this reflects WG consensus.

(Speaking as the author of shncpd -- I think it's a bad idea.)

> 3.3.  Resolution of local names

> IP addresses and names advertised locally MUST use addresses in the
> homenet's ULA prefix and/or RFC1918 prefix.

I do not understand this requirement.  Is it about direct or reverse
resolution?

> Homenet hybrid proxies MUST filter out global IP addresses, providing
> only ULA addresses,

Is this a restatement of the requirement above, or is it a new requirement?

> Artificial link names will be generated using HNCP.  These should only
> be visible to the user in graphical user interfaces in the event that
> the same name is claimed by a service on two links.

It is not our job to standardise the behaviour of GUIs.  If such advice is
desired, it should go into an informative appendix.

> 3.5.  Support for Multiple Provisioning Domains

> Homenets must support the Multiple Provisioning Domain Architecture [6].

As mentioned at the beginning of this mail, this does not represent WG
consensus.

> In order to support this architecture, each homenet router that
> provides name resolution must provide one resolver for each
> provisioning domain (PvD).  Each homenet router will advertise one
> resolver IP address for each PvD.

So not only does this document require having a DNS proxy on each router,
but it actually requires a complex form of split horizon.  I believe the
WG should think the consequences very carefully before committing to such
a path.

(Speaking as the author of shncpd -- this is out of the question as far as
I'm concerned.)

> When queries are made to the homenet-PvD-specific resolver for names
> that are not local to the homenet, the resolver will use a round-robin
> technique, alternating between service providers with each step in the
> round-robin process,

This is exactly the wrong thing to do, since it makes the Homenet resolver
as unreliable as the most unreliable of the providers' resolvers.

-- Juliusz