On Jul 20, 2016 00:13, "Toke Høiland-Jørgensen" <[email protected]> wrote: > > These are some fairly ambitious requirements, and I believe that they > > deserve discussion separately from the naming issue. More precisely: > > > > (1) Are wo to go to the effort of specifying and deploying a new ND option?
Why is this hard? > As I read this, it is mostly an optimisation and could be left out in > favour of simply timing out. Presumably the case it is solving (homenet > configuration lost) is so uncommon that having a simple timeout is > better than a new option that is probably not going to be very well > tested in any case. Maybe so. We should think about this. In any case, remember that the architecture document is the list of what are trying to accomplish. Seeing high goals is okay. If we realized that this is an optimization with little value, we don't have to do it. > > (2) Defining a management API goes against the Homenet tradition, which > > is to negotiate things over HNCP rather than defining new APIs. > > I agree that the "Restful API" sticks out a bit in the document. Restful is probably overspecifying. > Could the > document not just specify that there must be some way to configure it > appropriately, and leave the details to the implementations? This would represent failure. Leaving it to the implementation means no interop, which means vendor lock in. > As I read this, a resolver on each link is required to filter out > spurious DNS updates (last sentence in section 4.1). If some other > mechanism to prevent this is substituted, presumably the requirement to > have a resolver on every link could be dropped? Send text proposing this new alternative. However, it doesn't need to be a full blown resolver. It could just proxy. But there does need to be at least one resolver in the homenet. > Another thing that stuck out to me was the suggestion (in section 6.1) > to stick a captive portal in the user's face if there's a configuration > problem (or does "triggering captive portal detection" instead refer to > hijacking just the DNS names that, say, Android uses to detect the > presence of a captive portal?). Not sure I agree that's a good idea - > apart from captive portals being annoying as hell, this is again > specifying a UI element in detail; should the spec really do that? We need a way to contact the user. This is an easy way. I am open to other ideas. > Finally, the mechanism outlined in section 4.8 to use the homenet > services outside the homenet seems somewhat brittle to me. It involves > both caching logic and key management. I'm not sure to what extent this > is considered a killer feature. Would it be unreasonable to tell users > to simply add services they want to access from off-network to the > public zone? No. However, this is certainly a nice to have, not a must.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
