Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Steven Barth <[e-mail]>]

Hello Brian,

thanks for the comments.

On 19.11.2015 14:59, Brian Haberman wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * I see where HNCP describes how interfaces are classified as internal or
> external, but how does an interface get classified as leaf, guest, or
> ad-hoc?  Is this some manual configuration step that needs to be
> described somewhere?

These can only be manually selected. I have added a sentence:

  Note that all fixed categories
  except internal and external cannot be auto-detected and can only
  be selected using manual configuration.

to the second-last paragraph of the border discovery algorithm section.


> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
> uses the Internal category with the exception that HNCP traffic MUST NOT
> be sent on the interface, and all such traffic received on the interface
> MUST be ignored." The "all such traffic" is ambiguous. Based on the
> definition of the Guest category, I think "all such traffic" is really
> "all HNCP traffic".

I have changed it to

  Such an interface uses the Internal category with the exception that
  it MUST NOT operate as a DNCP endpoint.

to be in line with the changed definitions for the internal and external
categories (to address one of Ben's comments).


> * The text in section 5.3 seems incomplete. It gives a 4-step algorithm
> for border discovery, but says "if the node does not implement
> auto-detection, only the first step is required." If auto detection is
> not supported and a fixed category is not configured, what happens? Does
> this mean that if auto detection is not supported manual configuration of
> the border is required?

I changed it to "first and last" so the default is in line with the
default for the auto border discovery.


> * Section 7 describes how to handle non-HNCP capable routers. However, I
> don't see any operational issues described that could arise from having a
> non-HNCP capable router connecting two clouds of HNCP within the same
> home network. It seems like that could cause problems with a bunch of the
> services provided by HNCP.

I have added this as a paragraph to the applicability section:

  While HNCP routers can provide configuration to and receive
  configuration from non-HNCP routers, they are not able to traverse
  such devices based solely on the protocol as defined in this document,
  i.e., HNCP routers that are connected only by different interfaces
  of a non-HNCP router will not be part of the same HNCP network.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 3 has several ambiguous/confusing statements:
> 
> 1. Does "locally unique" mean unique to the node or unique to the
> link/network?

Clarified.

> 
> 2. On a node ID collision, which node re-computes? The one detecting, I
> assume.

Correct.

> 
> 3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?
> 

That phrase actually comes from the Trickle RFC
"The maximum interval size, Imax, is described as a number of
      doublings of the minimum interval size (the base-2 log(max/min))."



Cheers,

Steven