[homenet] Alissa Cooper's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-homenet-hncp-09: No Objection

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/



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

-- How does a node end up in the leaf or guest category? Is it only if a
fixed category is configured? If so, who decides that that configuration
should happen? I think this info belongs in the draft.

-- Section 5.1 says:

"Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the restrictions of the Leaf
      category, HNCP routers MUST filter traffic from and to the
      interface such that connected devices are unable to reach other
      devices inside the HNCP network or query services advertised by
      them unless explicitly allowed."

What is the mechanism for explicitly allowing selective access for guest
nodes? Is this left for firewall policy configuration? I think this
warrants some explanation.

-- In Sec 6.4, I'm unclear on whether the address selection process
specified in the bulleted list would ever be used to obtain a IPv6
address. If not, then this comment is not relevant. But if it might be
used in some case where the node is using v6 but for some reason cannot
use the mechanism specified in RFC7217, I think additional guidance is
needed here about self-assignment, in line with the ongoing work on
draft-ietf-6man-default-iids. Nodes might be tempted to embed a
link-layer address in the IID as a means of ensuring that their
self-assigned addresses do not collide with others, but they should be
discouraged from doing so. So I think some text to the effect that nodes
SHOULD assign themselves semantically opaque addresses even if they
cannot use the RFC7217 mechanism and SHOULD NOT embed the underlying
link-layer address in the IID is warranted here.