I haven't been following Ted's work on stub networks, and I've only just taken some time to read through the latest draft. Sorry if I repeat things that have already been said, I haven't caught up yet with my Homenet mail.
A few quick comments while I think it over. 1. There's a lack of definitions The draft speaks about "stub networks", but I couldn't find where the term is defined. Is a stub network a single layer-2 link, or can it be a layer 3 mesh ? Is a stub network connected through a single router, or can it be connected through multiple ones? If there are multiple stub routers, do they need to be connected to the same infrastructure link, or can they be connected to distinct links? To different providers (think BCP 38)? I think the draft could be usefully improved if the terms were more clearly defined. 2. There's a lack of a problem statement I couldn't work out what problem the draft is aiming to solve. In Section 3.2, it appears to be about client tethering, but in Section 3.5, it would appear to be about some sort of DMZ, that makes services available to the rest of the homenet. I think the draft would be improved if it were circuscribed by a clear problem statement. 3. NAT64 is controversial The draft recommends NAT64 as the IPv4 connectivity technique. I'm certainly not alone in this group in disliking NAT64, which combines all the problems of NAT with all the problems of split-horizon DNS. (See also RFCs 7368 and 9080, both products of this WG, which clearly discourage the use of NAT.) I think that the draft would be less contentious if the part about NAT64 were removed. Hope this helps, -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
