[v6ops] comments on draft-templin-v6ops-pdhost-13

[神明達哉 <[e-mail]>]

I've read draft-templin-v6ops-pdhost-13.  I found it generally well
written.  I have a couple of quick comments:

- Section 1

   'R' could instead function under the strong end system (aka "strong
   host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken
   from 'P' to an upstream interface as shown in Figure 3:

  I think this usage should clarify its relationship with the
  following part of RFC3633:

   [...] the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

  Perhaps the implicit assumption is that the "prefix" itself is
  assigned to a different interface than the upstream interface and
  should be justified.  But (even if so) I believe it should be at
  least explained explicitly, and I guess it could be controversial
  and should better reach an explicit consensus.

- Section 3

   In contrast, a node that configures addresses from a delegated prefix
   can assign them without invoking MLD/DAD on an upstream interface,
   since the prefix has been delegated to the node for its own exclusive
   use and is not shared with any other nodes.

  I personally think it still technically violates RFC4862 Section
  5.4:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

  These exceptions don't include "when the prefix is delegated to the
  host".  In fact, my understanding is that the sense of RFC4862 is
  quite strongly err on the side of caution and try to catch a
  situation of configuration errors - in the context of the draft,
  including cases where the upstream router accidentally assigns an
  address from the prefix.

  With some more discussion it may be justified, but I personally
  don't think the current brief description is enough.  Also, for this
  reason this document should be a standard track document updating
  RFC4862.

--
JINMEI, Tatuya