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

From: "Brian Haberman" <[email-masked]>
Date: Thu, 19 Nov 2015 05:59:29 -0800

Brian Haberman has entered the following ballot position for
draft-ietf-homenet-hncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

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

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

* 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?

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3 has several ambiguous/confusing statements:

1. Does "locally unique" mean unique to the node or unique to the
link/network?

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

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

* I support the other DISCUSS positions raised.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 19 Nov 2015 08:57:33 -0600

For what it's worth ...

> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

I don't think I"m reading this the same way Brian is, which does make a
case that it really is odd ...

Spencer

---

From: Steven Barth <[email-masked]>
Date: Fri, 20 Nov 2015 10:07:28 +0100

Hello Brian,

thanks for the comments.

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.

> definition of the Guest category, I think "all such traffic" is really

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

> this mean that if auto detection is not supported manual configuration of

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

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

Clarified.

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

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 Nov 2015 10:44:59 -0500

Hi Steven,
     Your response look good except for...

> categories (to address one of Ben's comments).

Two things on this.  First, is a Leaf interface on the router facing
devices that don't support HNCP or on the hosts facing an HNCP router? I
would think you would want this to be a category on the router.  Second,
I don't quite understand "DNCP endpoint". There is no definition of that
in either this spec or the DNCP spec. So, I am not sure what that would
entail for an implementer.

Regards,
Brian

---

From: Steven Barth <[email-masked]>
Date: Fri, 20 Nov 2015 17:58:48 +0100

> entail for an implementer.
The leaf category can be used for interfaces of HNCP devices on which
it doesn't which to speak HNCP, e.g. where only non-HNCP devices
are expected to be, e.g. a WiFi AP for clients. The point is to not speak
 HNCP if you don't have to which can increase security (see 12.2).

"Endpoint" is used and defined in DNCP, I called it "DNCP Endpoint"
to indicate it comes from that draft, however i can remove the "DNCP"
if that would make it more clear.

Cheers,

Steven