Thanks for the comments ;) On 18.11.2015, at 21.42, Alissa Cooper <ali...@cooperw.in> wrote: > -- How does a node end up in the leaf or guest category? Is it only if a > fixed category is configured? If so, who decides that that configuration > should happen? I think this info belongs in the draft.
Steven added some text on this related to some other DISCUSS: >Note that all fixed categories >except internal and external cannot be auto-detected and can only >be selected using manual configuration. > -- Section 5.1 says: > > "Guest category: This declares an interface used by untrusted client > devices only. In addition to the restrictions of the Leaf > category, HNCP routers MUST filter traffic from and to the > interface such that connected devices are unable to reach other > devices inside the HNCP network or query services advertised by > them unless explicitly allowed." > > What is the mechanism for explicitly allowing selective access for guest > nodes? Is this left for firewall policy configuration? I think this > warrants some explanation. I think this is implementation choice for now; doing it interoperably is not within scope of this document at least, although someone could provide some HNCP TLVs for distributed firewall configuration in the future. (I am not sure if such exist in the IETF wild currently.) > -- In Sec 6.4, I'm unclear on whether the address selection process > specified in the bulleted list would ever be used to obtain a IPv6 > address. If not, then this comment is not relevant. But if it might be > used in some case where the node is using v6 but for some reason cannot > use the mechanism specified in RFC7217, I think additional guidance is > needed here about self-assignment, in line with the ongoing work on > draft-ietf-6man-default-iids. Nodes might be tempted to embed a > link-layer address in the IID as a means of ensuring that their > self-assigned addresses do not collide with others, but they should be > discouraged from doing so. So I think some text to the effect that nodes > SHOULD assign themselves semantically opaque addresses even if they > cannot use the RFC7217 mechanism and SHOULD NOT embed the underlying > link-layer address in the IID is warranted here. I think it is essentially just fallback that I would rather not elaborate on - few reasons: - RFC7217 is the SHOULD; not doing SHOULD requires good idea on why not to anyway - the self-assignment preferences are likely to evolve over time (note: ongoing work) - we are mostly talking about routers (=few connections outside the home) not hosts => I am not that worried about the IID hiding However, if you can come up with a concise futureproof text that addresses the concern, I do not mind incorporating it. I personally am not sure how to phrase that. Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
