> 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  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 . 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 _______________________________________________ homenet mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/homenet