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

["Bernie Volz (volz)" <[e-mail]>]

Jinmei:

Thanks much for your thorough review!

Some comments below (inline, starting with **).

We are hopeful to receive further review comments so don't plan to publish an 08 revision until just before the IETF-91 draft deadline (Oct 27).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of ????
Sent: Wednesday, October 08, 2014 2:23 PM
To: Marcin Siodelski
Cc: [e-mail]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

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.

** The goal here is for this work to be an RFC. The 3315bis work is separate; obviously the 3315bis will want to incorporate the stateful issues changes. But we believe leaving the merged text to 3315bis is best. 3315bis may have other changes that impact the text in different ways.

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

** See above. And, yes the goal of 3315bis is to produce one document that unifies 3315 and 3633.

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.

** We will leave the title as it is.

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

** We will leave the abstract pretty much as is. We change last sentence to mention that the (RFC) changes are to address the identified issues.

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

** See below.

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

** We will rework the Introduction to remove the 'framework' concept and just focus on the IA_NA/IA_PD issues. When and if there are future IA's, those documents can indicate whether they integrate into this work (i.e., add IA_foo to IA_NA, IA_PD in the stateful issues document) or if they are separate and independent.

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

** We plan on making this change.

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

** We plan on making some of these changes (stateful options will stay).

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

** We plan on moving this rationale into section 4 (remove from section 1).

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

** No change planned; we feel that the text is sufficiently clear on this when compared with the original RFC 3315 text.

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

** While we could drop "and no delegated prefixes (...)", does that really help significantly especially since RFC 7083 material is being pulled in already? Also, in this case if we leave it out, people may be confused about what happens if there are no addresses but prefixes. (For most of the other changes later, RFC 3633 already covers these changes as it generally implies to replace "addresses" with "delegated prefixes" in much of the Reply processing. And, we've provided the revised text where needed for 3633.) Also, RFC 3633 already points to 17.1.3 of 3315 and this avoids having to specify replacement text for 3633.

- 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

** We will include this example and explain it. Note that T1b  = 0 means that the client must calculate the T1 time (50% of lifetime) and that it obviously needs to be less than T2b. So, in this case the T1b =0, T2b = 5 would be used but the T1b time is the 'implicit' time (we can't give the value since the lifetimes are not specified).

** There are perhaps other cases, for example T1a = 10, T2a = 20, T1b = 5, T2b = 25 that are a bit more interesting since picking (b) means T1=5/T2=25 which means T2 is longer than T2a.

** Perhaps we need to review whether the shortest 'effective' T1 and independently shortest 'effective' T2 are a better choice (obviously the client would have to adjust T1 if this means T1>T2, but I'm not sure that could even happen since for any individual IA, T1 must be less than or equal to T2). Note that by 'effective' here I mean either the server supplied value or, if 0, the client determined value based on the lifetimes within that IA.  If we used that algorithm, for your case the answer would not change; for my example T1 would be and T2 would be 20 which are probably better values for this case.

** Comments about this issue (and perhaps additional case analysis if appropriate) would be useful.

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

** We will create a 3315bis ticket since this is pre-existing text used "as is" from 3315. And, this is not an issue that is particular to this draft. Note that Confirm is IA_NA (IA_TA) specific as IA_PD requires a Rebind; so this is an open issue in the original 3315 and should be added by the bis document. It also is more of a clarification, rather than a "change". The bis document can clarify that when a client sends a Solicit, it MUST not be using any of the addresses or delegated prefixes for the bindings included in the Solicit.

** Note also that it appears the original 3315 text missed specifying the actions for NotOnLink for Renew and Rebind.

** We've opened a new DHCPv6bis ticket for this - http://trac.tools.ietf.org/group/dhcpv6bis/ticket/123.

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

** Yes, this seems to have been done in error. We will revise. Restarting DHCP discovery process should only be done if there are no addresses/prefixes at all.

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg