[dhcwg] comments on ietf-dhc-topo-conf-01

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

I have some small (and maybe a bit out of scope) comments on the
draft.

- page 6 (Section 3) it states:

   [...] If for whatever
   reason that is not feasible (e.g. because the relay agent does not
   have a global address), the relay agent includes an interface-id
   option that identifies the link clients are connected to.

  In the "e.g." part, "the relay agent does not have a global address"
  means it doesn't have a global address configured on the
  client-facing interface, right? (Otherwise it's very unlikely for
  the relay agent to reach DHCPv6 servers).  But this sentence could
  also read as if the relay agent doesn't have any global address on
  any of its interfaces.  Maybe it's not that confusing in the entire
  context, but I think it's better to revise it so it will be even
  much less confusing.

- and on the next sentence:

   [...] It is up
   to administrator to make sure that the interface-id is unique within
   his administrative domain.

  Is it expected that an administrator would use interface-id's unique
  even outside of the relay agent?  While RFC 3315 doesn't seem to be
  very specific, I thought interface-id's would be generally only
  unique within that particular relay agent (an DHCPv6 relay agent
  implementation I previously worked on used the OS interface index
  for the interface-id).  While this sentence is not incorrect since
  it only says "it's up to admin", the tone of this sentence is a bit
  surprising to me, and I wonder what's the common practice in other
  implementations and actual deployments.

- also in Section 3 (page 7), this paragraph isn't very understandable
  to me:

   In all cases, then, the DHCP server will have a link-identifying IP
   address, and in some cases it may also have a link-specific
   identifier.  It should be noted that there is no guarantee that the
   link-specific identifier will be unique outside the scope of the
   link-identifying IP address.

  What's "link-specific identifier"?  Is this a higher level concept
  that means
  - global address for the link-address field when provided, or
  - the interface-id option value when provided or mandated
  ?  The second sentence is also not really clear to me...what does
  "outside the scope of the link-identifying IP address" mean?
  Usually "the link-identifying IP address" should be global, so there
  is basically no "outside the scope" of it in the first place.
  I guess these are mostly an editorial matter rather than a technical
  issue, but in its current form this paragraph is very confusing to
  me.

- In Section 8, it states:

   [...]  When changes are made to the DNS server, these changes are
   immediately and automatically adopted by the DHCP server.

  I'm afraid "immediately" is not very accurate, since it's more likely
  that the DHCP server actually uses some caching server and a change
  at the DNS server (or more accurately, zone) won't be visible to the
  DHCP server until the cache expires.  Of course, it's the DNS
  admin's responsibility to make sure that the cached information is
  valid until all cache of it expires, but that's different from the
  new information being "immediately adopted" by the DHCP server.
  Also related, this paragraph actually talks about two different
  types of DNS servers (or their administrators"): the caching DNS
  server that the DHCP server uses and the authoritative DNS server
  that manages the information that the DHCP server would ultimately
  need.  It would probably be clearer if this paragraph differentiates
  these two types of DNS servers according to the appropriate context.

--
JINMEI, Tatuya