Last Call Review of draft-ietf-homenet-dncp-07
review-ietf-homenet-dncp-07-opsdir-lc-kuarsingh-2015-08-03-00

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