On 4.3.2014, at 18.06, Steven Barth <[email protected]> wrote: >>> 2. Related to the previous point, is everything MUST, or should some >>> parts be made optional? I'd personally like the DNS proxy stuff to be >>> made optional. >> Agreed. It started as a separate draft and MUST in separate draft was >> sensible but now, well.. I’m wondering even about PA stuff, because if you >> want to use different algorithm, it should be ok as long as you publish your >> delegated/assigned things in a compatible way. > I suppose we want to differentiate between transport and payload here. > I'm not sure if splitting it up into individual drafts might make sense > but definitely - as I also pointed out in the presentation - it wasn't > meant to be interpreted in a way that any of the non-protocol related > TLVs are mandatory. Though in practice there are some inter-dependencies > between payloads atm, e.g. both the fallback-routing and the DNS/SD > stuff somewhat reuses prefixes and / or address-information announced by > the PA-mechanism.
Splitting TLV-only content to separate drafts (especially now that they have little extra content) probably wouldn’t help much. (Mostly because it would create bunch of very minimal drafts with at least strong dependencies on the generic drafts, and the core draft). I suppose the right way forward on that front is just to specify that extra feature sets are SHOULD/MAY-ish, and if implementing that feature set, relevant MUST/SHOULDs there. >>> 3. There would appear to be no way to specify "please carve this >>> prefix into /64 or shorter" as opposed to "please feel free to grab >>> a /128 in this prefix”. >> Hmmh. Do you think it’s issue in the hncp-00 or prefix-assignment one? I’m >> not exactly sure I want ‘purpose’ bits for delegated prefixes. (see above >> also on mandatoriness of prefix-assignment _draft_) > I don't know if we really consider a /128-assignment to be a prefix in > that sense. I would see this as a special case to aid in meshing and > similar so I think maybe adding a special kind of _assigned_ prefix type > of some sort might make sense for this from which every (supporting) > router should be able to pick a /128 regardless of the link. We already have that assigned address TLV anyway, so given extra assigned prefix bit (we have 3 reserved ones), it could be probably fairly straightforward to do /128 allocations using this. Logic along the lines of: - if /128 allocations are desirable, allocate one assigned prefix with <whatever size> and bit X=1 (possibly even allow multiple ones in race cases?) - and then just allocate stuff from there. >>> 5. I don't think the routing protocol should be negotiated by the >>> config protocol, since that implies that the routing daemon is started >>> by the config daemon. The routing daemon(s) should be started at >>> boot, and notice when the config daemon adds IP addresses to >>> interfaces. Knowledgeable people appeared to disagree. > I would disagree here. I don't see the point in starting the daemons for > homenet-interfaces here if they have to wait for HNCP to assign prefixes > / addresses anyway. I suppose that if you were ambitious and wanted to run this non-root on non-suid binary system (e.g. Android) it would make sort of sense, because you’d want to do things as root early in the boot time and then just configure existing services (with sufficient privileges to do what is needed). > I wouldn't really do it like that. Even though I agree with the 0-1 or 1 > routing protocol agenda I wouldn't really do negative capability > announcements. If for some reason you want to make changes or use HNCP > for other purposes later this will get ugly. Hmmh, with 1 routing protocol agenda negative capability is not really needed in any case (in that one, you just assume routing happens and everyone lives happily ever after). So how do you think the 0-1 should be done? - option a: negative capability indication, mixed network (what I wrote) - option b: ‘support protocol X/Y/Z’ => mixed network (with explicit support for fallback too(?), somehow know/avoid bad combinations?) - option c: ‘support protocol X/Y/Z’ => 0/1 routing protocol in whole home If I were <random ISP customer>, and they sent me braindead router, I’d be unhappy with option c as it would force 0 routing protocols in whole home. But that’s where you’d get with e.g. current hncp-00 text. Same thing with transitions between 0 and 1 routing protocols in a whole network, which I would rather avoid. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
