Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

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

At Thu, 02 Oct 2014 11:10:48 +0200,
Marcin Siodelski <[e-mail]> wrote:

> The version -07 of the draft-ietf-dhc-dhcpv6-stateful-issues is now
> available at:
>
> http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/
[...]
> Please provide your comments. Note that this work builds the ground for
> the RFC3315bis, so your interest is important.

Here's my review.  I almost forgot the full context of the discussion
regarding my previous review comments, so I might simply repeat some
points I made before.  Hopefully they are still valid.

First, I have a couple of higher level points to discuss:

- What's the final goal of this document?  Is it supposed to be
  published as a separate RFC, or is it just a placeholder for
  discussion for 3315bis and is supposed to be dropped once the result
  is incorporated to 3315bis?  I'm asking this because in its current
  form this document relies on the fact that readers are pretty
  familiar with the discussion context and won't be friendly for
  future readers if published as a separate document.  But if the goal
  is the latter of the above two, it's probably okay and it would be
  more constructive to just discuss purely technical matters rather
  than try to make it (more) readable for first-time readers.

- I'm not necessarily opposed to it, but why this?

> 5. Removed the "unified" text (intended for RFC3315bis) from the
> Renew/Rebind sections. The current text only provides respective updates
> for RFC3315 and RFC3633.

  If the eventual goal is to unify 3315 and 3633 in 3315bis (I
  personally didn't think it a very good idea, but I wouldn't argue on
  that point in this context), such unification will be eventually
  inevitable.  So shouldn't it rather better to discuss it sooner
  (i.e., in this draft) than later?

Specific comments to the draft text follow:

- Title: now that our main focus is the mixed use of IA_NA and IA_PD
  rather than generalizing the concept of stateful resources, I think
  it makes more sense to reflect it in the title, for example,
  "Issues and Recommendations with Multiple DHCPv6 IA Options".
  See also my comments on Section 3 (terminology) below.

- Abstract: this is more about readability (see above), but I'm afraid
  the current abstract text wouldn't be really helpful for first-time
  readers (on the other hand, it's not a problem for "me", because I
  already know what it is).  At the very least I'd briefly summarize
  the actual proposals here.  On the other hand, I don't see the
  sentence that refers to RFC 7084 in this context (it's useful in
  Introduction, but not for abstract).

- Section 1: this is not a complete sentence:

   [...] And, to provide a framework to support
   new IA option types, assuming they are similar enough.

  probably it's just expected to be a continuation of the preceding
  sentence? "requested as per [RFC7084], and to provide...".

- Section 1, regarding the same text and this one:

   [...]  Future
   documents that define new IA option types will need to specify
   whether they fit into this framework or define the DHCP operation for
   the new and existing IA option types, as appropriate.

  IMO, this document should talk a bit more about the "framework".
  I'd suggest explaining these, for example: this framework is based
  on some assumptions, including:
  - An IA option has the concept of T1/T2 values for renew and rebind,
    and the semantics is same for all these IA options types
  - The information (or a set of it) assigned in IA is associated with
    a lifetime.
  - These multiple IA options are expected to be assigned as a set,
    and it's generally considered an operator's error if a DHCPv6
    server can only provide a subset of it, even if it's not rejected
    by the protocol. (without this assumption, we could have an
    awkward situation, e.g., where a client request both IA_NA and
    IA_PD and the server only replies with IA_NA, and the client can't
    get IA_PD at least until the first renew or unless reconfigure is
    made possible)

- Section 1, on the paragraph talking about IA_TA:

   Note that while IA_TA (temporary addresses) options may be included
   with other IA option type requests, [...]

  I have a feeling that this paragraph is incomplete.  That is, I'd
  say "so what?" on reading this paragraph.  My suggestion is to
  clearly declare that the mixture of IA_TA and other types of IAs is
  out of scope of this document.  In fact, IA_TA doesn't fit in the
  framework shown in the previous bullet (as it doesn't have T1/T2),
  and we won't be able to well-define it.  And we can probably justify
  the decision based on the observation that it "has limited value".
  This paragraph would make sense if it's provided with such a
  decision.

- Section 3: now that we've limited the scope of this document
  mainly focusing on the specific case of IA_NA and IA_PD, I
  suggest simplifying the terminology.  It would be more
  reader-friendly if the reader doesn't have to understand fewer
  concepts as a prerequisite.  Specifically:
  - remove "resource".  I don't see the need for this generalized
    concept anymore.  In fact, other than in this particular section,
    this term is used only once (Section 4.1)
  - replace "stateful options" with "IA options" (and to this end we
    might not bother to list in the terminology section explicitly)

- Section 4: I suggest adding the rationale of the proposal.  In its
  current form the proposal seems to be suddenly given without
  explaining why.  Even if some hints are (seemingly) scattered in
  other sections of the document, I believe this should be the primary
  place to give it.

- Section 4.1, regarding the replacement for RFC 3315 17.2.2:

      If the server will not assign any addresses to an IA in a
      subsequent Request from the client, the server MUST include
      the IA in the Advertise message with no addresses in the IA
      and a Status Code option encapsulated in the IA containing
      status code NoAddrsAvail.

  Maybe we should also say "the server MUST NOT place a Status Code
  option for an IA at the top level".

- Section 4.2: replacement for RFC 3315 17.1.3:

     The client MUST ignore any Advertise message that contains no
     addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
     and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
     options, see RFC 3633) with the exception that the client
     MUST process an included SOL_MAX_RT option (RFC 7083), MUST
     process an included INF_MAX_RT option (RFC 7083), and MAY
     display any associated status message(s) to the user.

  It's awkward to see it mention prefixes while this version
  intentionally cancels the idea of "unified" text for renew/rebind.
  It's not clear to me why Section 17.1.3 (regarding advertise) still
  needs to provide "unified" text.

- Section 4.3: I don't understand the following text:

   [...] To deal
   with the case where servers have not yet been updated to do that,
   clients MUST use the shortest (explicit or implicit) T1/T2 times
   (larger than 0), from the same IA option, in the Reply.  T1/T2 times
   from other IAs are ignored.

  I guess it tries to address the corner case I pointed out for the
  previous version of the draft:
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15663.html
  but I don't even understand what the client would do in this case
  based on the new text.  To recap, what should happen if the client
  sees the following two sets of T1/T2 according to the above text?
  - T1a = 10, T2a = 20
  - T1b = 0, T2b = 5

- Section 4.4.5: does this mean, if the client has bindings of
  multiple IAs, it should (effectively) abandon all of the bindings
  and establish new bindings for all of the IAs starting from Solicit?
  If so, it makes sense to me, but it's not really clear from the
  text, and I suggest clarifying that point.

     When the client receives a NotOnLink status from the server in
     response to a Confirm message, the client performs DHCP server
     solicitation, as described in section 17, and client-initiated
     configuration as described in section 18.

- Section 4.4.5: I'm not sure if I understand this:

     -  Tries to obtain the IA from another server (by restarting the
        DHCP discovery process) if the client attempted to obtain a new
        binding in the Renew or Rebind message by sending an IA without
        any addresses and the server responded with NoBinding status
        code.

  What if the client has a binding for another IA (and it's
  successfully renewed in this response)?  If the above means the
  client starts a new DHCPv6 session for the IA that doesn't have a
  binding separately from the other IA with a binding, it seems to
  break the main idea of this draft: maintaining a single DHCPv6
  session for all IAs.  So does this mean the client terminates the
  existing DHCPv6 session and tries to establish all bindings for all
  IAs from Solicit?

--
JINMEI, Tatuya