Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is for the Standards Track. This document describes the HNCP (Home Networking Control Protocol) which is a profile of the DNCP (Distributed Node Consensus Protocol). HNCP provides automated contribution of addressing, naming, boarder detection and is intended to inter-operate with a separate routing protocol. HNCP is targeted at a home network and is adherent to the homenet architecture (RFC7368) The document is well written and has received significant comments and updates (currently at version -07). NIT: Section 6.4., P1, Change “HNCP routers can create an ULA” to “HNCP routers can create a ULA” Comments / Feedback / Questions: Suggestion: Section 7.1, P2. The HNCP router with the greatest H-capability is desired to win if there are more then one DHCPv6 servers. There is text following that say “In case of tie, Capability Values and node identifiers are considered (greatest value is elected). - I was wondering if this text is specific enough to create deterministic results. Would some text which specific notes which additional values are use in what order? When looking at Section 10, I would think it’s possible (likely a corner case), that the M, P, H, and L capabilities may all be set to 7 (understanding it’s not default, but possible). - Section 7.3 has some text which specifically callout highest node value for ties (referring to P-capability), so perhaps that explicit text in section 7.1 is beneficial ? Section 7.1: P2. On this same note, I may have missed the text somewhere, but what happens in a situation where you have two HNCP routers, and one (likely fault condition), may go offline/online frequently and when on, would normally be elected as the preferred HNCP router. Is some persistence on which HNCP router needed to keep the the network stable? Section 7.4. P3. I see that the text notes that the implementer should set short least times to help allow the network to deal with changes. Would an alternative approach this this be valuable? Perhaps using the T1/T2 timers to help hosts seek rebinding early, but allow the lease times to be longer (this may provide the same result, but not require leases to pop as frequently). This is just an suggestion. This strategy has been used in operational networks to deal with renumbering and may be beneficial here (or may not - I will allow the authors to make the determination). Section 10: Node version of 0 appears to have been skipped (saw that in rev changes based on deployments using version 1). I would assume that future HNCP routers will use higher version numbers, and that older version HNCP routers would not participate. I would also guess that in the future, higher HNCP routers may use some compatibility mode to deal with lower version HNCP routers. However, I am not quite sure based on text, what the behavior will be. I.e if an older HNCP routers sees a neighbor advertise version 2 (where local router is version 1), will it just stop talking HNCP? - or will it re-try in a while such that if the neighbor router revs down to local router, it can then participate in the homenet? Continuing on this, should Version 0 just be reserved for testing / development for now so it gets an explicit assignment (given it’s a lower version then the current start point of version 1)? General comment: The document refers to a routing protocol often, but does not name one. I know that the discussion in homenet continues to battle this question, but it appears to be that it’s not 100% clear how this interaction should be implemented. I heard comments before which state that perhaps the interaction is with the local routing table which would then make the discussion more generic (i.e. how a routing protocol works along side the routing table is well separated with how HNCP interacts with the routing table). Along this point, it’s possible that the routing protocol of preference may change over time, and that may or may not be attached to HNCP release versions. So perhaps we should make that explicit? I would think if the separation is stated more clearly (i.e. the integration of HNCP with routing protocol is somewhat separate), then this point becomes benign. There then these comments and questions, I feel the document is well written and based on current implementations, is well put together. regards, Victor K