Last Call Review of draft-ietf-homenet-dncp-07

Request Review of draft-ietf-homenet-dncp
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-07-29
Requested 2015-07-19
Authors Markus Stenberg, Steven Barth
Draft last updated 2015-08-03
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Genart Telechat review of -09 by Meral Shirazipour (diff)
Genart Telechat review of -10 by Meral Shirazipour (diff)
Genart Telechat review of -11 by Meral Shirazipour (diff)
Opsdir Last Call review of -07 by Victor Kuarsingh (diff)
Opsdir Telechat review of -09 by Victor Kuarsingh (diff)
Rtgdir Early review of -03 by Les Ginsberg (diff)
Rtgdir Early review of -05 by Thomas Clausen (diff)
Rtgdir Early review of -03 by Lizhong Jin (diff)
Assignment Reviewer Victor Kuarsingh 
State Completed
Review review-ietf-homenet-dncp-07-opsdir-lc-kuarsingh-2015-08-03
Reviewed rev. 07 (document currently at 12)
Review result Has Issues
Review completed: 2015-08-03



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).


Section 6.4., P1, Change “HNCP routers can create an ULA” to “HNCP 

routers can create a ULA”

Comments / Feedback / Questions:


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 


- 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.


Victor K