Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

From: 神明達哉 <[email-masked]>
Date: Thu, 1 Jun 2017 11:53:01 -0700

On Fri, May 26, 2017 at 10:56 AM, Bernie Volz (volz) <[email-masked]> wrote:

>>> - I'm okay with deprecating the delayed authentication protocol, but
>>> I'm not sure if it's okay to ship the spec with no built-in
>>> authentication (the reconfigure key protocol is very limited and too
>>> weak).
>
> BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:
>
>    Many of these rogue server attacks can be mitigated by making use of
>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be
clear, I'm not requesting sedhcpv6 be specified as *the*
authentication protocol in rfc3315bis.  But I'd suggest chairs to
explicitly leave notes about the point for security ADs when the doc
is sent to the IESG.

>>> - Section 5.2
>>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>>  s/RFC2462/RFC4862/.
>
> and there are still more references to RFC2462.
>
> BV> This is by design. RFC4862 does not mention the M & O bits so we
> can't reference that RFC. We documented the reason for this in
> Appendix A:

I believe at least the reference to RFC2462 in Section 6.2 is not
really appropriate:

   This model of operation was the original motivation for DHCP and is
   the "stateful address autoconfiguration protocol" for IPv6 which is
   discussed in [RFC2462].

Simply because RFC4862 doesn't use the term "stateful address
autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862
just replaced it with the term "DHCPv6".  If you want suggested text,
my suggestion is simply remove the second half the sentence:

   This model of operation was the original motivation for DHCP.  It
   is appropriate for situations where stateless address
   autoconfiguration alone is insufficient or impractical, e.g.,
   because of network policy, additional requirements such as dynamic
   updates to the DNS, or client-specific requirements.

As for the references to RFC2462 due to M/O RA flags, I still think it
can be rather misleading.  The sad fact is that M/O flags are dead -
all previous attempts at the 6man wg of making them workable failed,
and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me
newer protocol documents like rfc3315bis still talk about them simply
because its predecessor talked about them.

Now, if you want suggested text, this is my suggestion:

Section 18
OLD
   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  A client
   has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462] Section 5.2),
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

(unrelated) side note: there's a duplicate bullet #4 here.

Section 18
OLD
   The client has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462])
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

Section 18.2.1
OLD:
   In the case of a Solicit message transmitted when DHCP is initiated,
   the delay gives the amount of time to wait after IPv6 Neighbor
   Discovery causes the client to invoke the stateful address
   autoconfiguration protocol (see section 5.5.3 of [RFC2462]).  This
   random delay desynchronizes clients which start at the same time (for
   example, after a power outage).

NEW: I actually suggest removing this paragraph.  Especially given M&O
flags are "dead", I don't see a strong reason for retaining it in
addition to its previous paragraph (which also talks about the delay
and for the case of power outage).  If we still want to say something
about the interaction with RA, my suggestion is to revise the previous
paragraph as follows:

   The first Solicit message from the client on the interface SHOULD be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
   mechanism is essential for devices that are not battery powered, as
   they may suffer from power failure.  After recovering from a power
   outage, many devices may start their transmission at the same time.
   This is much less of a concern for battery powered devices.  This
   random delay also helps descynronize clients which start DHCPv6
   session by seeing it available in Router Advertisement messages
   (see Section 4.2 of [RFC4861]).

Note that if all of the above suggestions are adopted, there will be
no reference to RFC2462.  So you can also remove it from the
Refereneces section.

>>> - Section 5.4
>>> [...] the requesting router MUST set the valid lifetime in those
>>> advertisements to be no later than the valid lifetime specified in
>>> the IA_PD Prefix option.
>>>  "no later than" sounds awkward as the lifetime is a duration, not  a
>>> particular point in time.
>
> This is simply open as before.
>
> BV> Unless you suggest some text, we will leave this be. I think the
> point of the text is rather clear.

If you want suggestion, this can be fixed easily:
NEW:
 [...] the requesting router MUST set the valid lifetime in those
 advertisements to be no larger than the valid lifetime specified in
 the IA_PD Prefix option.

i.e., s/later/larger/

>>> - Section 8.1
> [...]
>
>>> site-scope unicast address has been deprecated.  Also, the phrase
>>> "global or ULA" is awkward as ULA is a global (scoped) address.
>
> The 08 version states:
>
>                            This is typically a globally unique
>                            address or unique local address (ULA)
>                            [RFC4193],
>
> This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".
>
> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

I've already suggested text (I admit the point may be a bit pedantic,
though).

>>> - Section 17.1.10.1
>>> "no later than" sounds awkward for these lifetimes (see also Sec
>>> 5.4).
>
> BV> See above.

Ditto:-)

>>> - Section 17.1.10.1
> [...]
>>> Specifically, the bullet description seems to lead to multiple
>>> separate state machines for different bindings.
>
> BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:
>
>    The server controls the time at which the client should contact the
>    server to extend the lifetimes on assigned leases through the T1 and
>    T2 parameters assigned to an IA.  However, as the client Renews/
>    Rebinds all IAs from the server at the same time, the client MUST
>    select a T1 and T2 time from all IA options, which will guarantee
>    that the client will send Renew/Rebind messages not later than at the
>    T1/T2 times associated with any of the client's bindings (earliest
>    T1/T2).

Hmm...this is one of the things why I can't be confident about this
spec without actually trying to implement it from the text.  But I
don't have enough time to check if the concern is addressed in the
entire context, I'll simply give up with it.

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new
> text simply avoids saying specifics about these lifetimes, but then
> it's even more unclear about what these lifetimes are (especially
> the preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior,
and I don't even know if we have common consensus on it.  I also think
we can't simply ignore the issue by being silence, since it could
result in a bad situation like a site keeps advertising a prefix in RA
as a preferred one even when it's already "deprecated" or even
"invalidated" in terms of prefix delegation.  I'll see if I can offer
something more concrete, but I'd like to raise it as a possible
blocking issue.

>>> - Section 20.23
> [...]
>>> The expected usage is not very clear to me here.  Is it intended to
>>> be used for Advertise and apply the value to the ongoing
>>> Solicit-Advertise exchange?  Or is it mainly intended to be used for
>>> a possible subsequent restart of a DHCPv6 session?
[...]
> BV> You original question was I think about why SOL_MAX_RT MUST be
> in ORO. It MUST be as per RFC 7083 so that clients can get updated
> SOL_MAX_RT values. And, yes, the idea is that the Advertise with the
> SOL_MAX_RT value is used (even if it offers no leases) so that the
> client applies this value for any future requests. I don't see the
> need for this to be spelled out?

I'd think it's worth explaining, but I'll leave it to you.

--
JINMEI, Tatuya

---

From: Shawn Routhier <[email-masked]>
Date: Thu, 8 Jun 2017 01:50:33 +0200

Here are the comments I received from Shawn Routhier. He asked me to
relay them to the DHC list due to some e-mail issues.

Nits:

Section 1.1
"Service for IPv6s" => "Service for IPv6"
"errata filled" => "errata filed"

Section 4.2
DHCP Client: "it may feature the" => "it may include the"
DHCP Server: "it may also feature the" => "it may also include the"
Feature isn't wrong but it is a bit odd.

IA: "and identity association for" => "an identity association for"

singleton option: "once as a the" => "once as a"

It probably would have been useful to include a definition
of "other configuration"

5.3
"updates its configuration" => "update its configuration"

6
"the servers via specific interface," => "the servers via a specific
interface,"

6.6 para 3
"to request larger prefix" => "to request a larger prefix"

7.3
REPLY: "Solicit, Request, Renew, Rebind" => "Solicit, Request, Renew or
Rebind"

11 para 2
"such are those defined" => "such as those defined"

16 para 2
"ignore such message completely" => "ignore such a message completely"

18.2.4
"include IA Prefix option with the IPv6-prefix" => "include an IA Prefix
option with the IPv6-prefix

"is terminated when earliest time T2" => "is terminated when the
earliest time T2"

18.2.10, para 2
"options in an Reply" => "options in a Reply"

Not quite nits, but still not major

6.3, last paragraph
The text goes from client to router and back to client.  It might be a
bit better as

   If the client assigns a delegated prefix to a link to which the
   client is attached as a router, and begins to send router
   advertisements for the

6.6
This section discusses multiple addresses via multiple IA_NA or IA_TAs
should it include any text about multiple addresses per IA_NA or IA_TA
(even if that text is simply to discourage it)?

12.2
This section has the line "A client must create at least one distinct
IA_PD" It would be useful to qualify that to only clients that want a PD
need to have an IA_PD.

18.2.4
I'm unclear why the last paragraph (about moving from renew to rebind
at T2) has the the extra text about reconfigure.  It seems to be it
could be stated a bit more bluntly:

  The message exchange is terminated when the earliest time T2 is
  reached and The client begins a Rebind message exchange (see Section
  18.2.5). If the client was responding to a Reconfigure, the client
  ignores and discards the Reconfigure message.

18.3 para 3
"a Reply in response to a Request," => "a Reply in response to Request,"

18.3.2
There are a couple of typos in this ppart of the text and I'm not sure
what "the presence" refers to.
   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires an authentication
   and currently the only defined one is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence or
   reconfigure key signals support for Reconfigure acceptance.  However,

I think this is what it is trying to say

   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires authentication
   and currently the only one defined is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence of a
   reconfigure key signals support for Reconfigure acceptance.  However,

21.4
'non-temporary addresses; "it is up' => 'non-temporary addresses; it is up'

(there is an extra double quote in the sentence)

Tomek Mrugalski
(on behalf of Shawn Routhier)

---

From: Shawn Routhier <[email-masked]>
Date: Thu, 8 Jun 2017 01:50:41 +0200

Nits:

Section 1.1

Section 4.2

5.3

6

6.6 para 3

7.3

11 para 2

16 para 2

18.2.4

18.2.10, para 2

6.3, last paragraph

6.6

12.2

18.2.4

18.3 para 3

18.3.2

21.4

Tomek Mrugalski

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Jun 2017 20:34:42 +0000

Kim:

Thanks for the thorough review. I think I did (almost) all of these. You will see them in the -09 when published.

One that I skipped is #19 as we use this convention in other places (total of 7) in the document when the reference is just for informational purposes (following the reference isn't key to the point being made and is just "For Your Information" if you case). I have raised it for the co-authors to discuss to see if we want to remove the parenthesis everywhere, switch to commas, or leave as is. We may also just punt this to see what the RFC-Editor may do.

For Appendix B and C, there were a bunch of issues with these and I think they have been corrected (there a few other issues). I also wonder whether we should just drop these as I'm not they add much value -- and likely if something if "off" in them, may cause more confusion. So, another point to be raised to the co-authors.

The co-authors are expecting to discuss the issues on Wed June 14th @ 0800 EDT. Those interested in participating in that discussion can contact me for meeting details (https://jitsi.tools.ietf.org/dhcpv6 or webex in case jitsi has issues - it sometimes does).

- Bernie

-----Original Message-----
From: Kim Kinnear (kkinnear) 
Sent: Thursday, May 18, 2017 3:15 PM
To: [email-masked]; Ralph Droms <[email-masked]>
Cc: Kim Kinnear (kkinnear) <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Folks,

I did a pretty complete review of the document, and while most of the
first issues I found were editorial, I found a number of technical
issues as I went along.  Of the 33 issues I found (all of which I felt
important enough to write down), the following stand out as
particularly important:

Editorial: #8, #23

Technical: #10, #14, #15, #16, #17, #20.5, #21, #22, #26
           #27, #28, #30, #31, #32

I have read this document, and I approve its moving forward.

I would very much like to see the issues I've highlighted above
addressed, either by taking my suggested corrections, or by explaining
why the document is correct as it stands.  

As it happens, a few of the issues I found were from RFC 3315
and not added by the -bis process.  But, as I commented below,
that doesn't make them correct.  

Here are the issues:

1. Section 11, para 2, "such are those" -> "such as those"

2. Section 11, para 3, last sentence, "as specfic in" -> "as specified in"

3. Section 13.2, para 4, "... with additional condition that the new
   address is not duplicated with any assigned addresses" -> 
   "... with the additional condition that any new address is not 
   the same as any assigned address."

4. Section 13.2, para 7, "of temporary address is unlinkability of different
   actions over time." -> "of a temporary address is to make it 
   difficult to link the address to different actions over time."

5. Same as above, "though DHCP provides such possibility" -> 
   "though DHCP provides for such a possibility"

6. Section 14.2, list with 3 elements.  I think we want to remove
   the ", and" at the end of item 2, the comma at the end of item
   1, and the period at the end of item 3.  In particular, the 
   ", and" kind of implies that item 2 and item 3 are linked, but I
   don't think they are.

7. [retracted correction: diff had a problem not present in the actual draft]

8. Section 18, para 5.  Paragraph beginning with "The client has many..."
   and containing a list with 4 elements.  This list appears to have been
   moved to the first part of the section and slightly improved there, 
   and it looks like this older version of the list should have been 
   deleted.

9. Section 20.4.1.  para 3 (or 2, depending on how you count).  
   "The format of the Authentication information..."
   -> "The format of the authentication information ...".  In the option
   description (21.11), "authentication information" is not capitalized.

10. Section 20.4.3, para 1, "... in the initial Reply ..." -> "... in an 
    Authentication option in the initial Reply ..."

11. Section 21.4, para 2 after table after Figure 15. "Each IA_NA ... attached
    to." -> "Each IA_NA carries one "set" of non-temporary addresses; it is up
    to the server policy to determine how many addresses are assgined,
    but typically at most one address is assigned from each prefix assigned to
    the link to which the client is attached."  Note removal of double quote
    before 'it' as well as improved wording.

12. Section 21.5, para 6 after table after Figure 16. "... MAY request that
    valid lifetime ..." -> "... MAY request that the valid lifetimes ...".
    Two changes, added "the", and made lifetime plural.  I'm not positive
    about making lifetime plural here, please validate that.

13. Same para as #12, "Extending only valid but not preferred ..." ->
    "Extending only the valid but not the preferred ..."

14. Section 21.6, para 1.  The last sentence "The Options fields
    of the IA_NA or IA_TA option encapsulates those options that are 
    specific to this address." hasn't changed since the -05 draft, but
    it *is* different from RFC 3315, which said: "The Options field
    encapsulates those options that are specific to this address."
    I find the current language confusing.  Why would the Options
    field of the IA_NA or IA_TA encapsulate options that are specific
    to this address, when there can be multiple IA Address options in
    an IA_NA or IA_TA?  I would have expected this sentence to read
    "The IAaddr-options field encapsulates those options that are
    specific to this address.", since there seems to be no other 
    point to having an IAaddr-options field.  But in any case, this needs
    to be figured out and fixed, as it is plenty confusing as it now
    stands.

15. Section 21.7, para 1 after table after Figure 18.  

    Sections 21.24 and 21.25 state that the SOL_MAX_RT and
    INF_MAX_RT options MUST always be in every Option Request option.
    But this is contradicted by Table 1, which says that they MUST
    only appear for certain message types.  I believe that Table 1
    is in fact more correct than the statements in Section 21.24 and 21.25.
    In which case, I would suggest that a new sentence be added here:
    "For certain message types, some Option codes MUST be included
    in the Option Request option, see Table 1 for details."

    And, Sections 21.24 and Section 21.25 should be corrected to
    mention the message type qualification:

    Section 21.24, para 1 after table after Figure 38:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    a SOLICIT message."

    Section 21.25, para 1 after table after Figure 39:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    an Information-request message."

16. Section 21.7, para 2 after table after Figure 18. "Only container
    options MUST appear in the Option Request," --- I think that this 
    is simply incorrect.  The better way to say this would be "Only container
    options MAY appear in the Option Request option,", but that is also
    incorrect.  I believe that the statement is "Only top-level options
    MAY appear in the Option Request option."  The next sentence
    should then be: "Options encapsulated in a container option MUST
    NOT appear in an Option Request option, see [RFC7598] as an
    example of container options."  

17. same as #16.  I think the last sentence should be replaced with 
    "Options MAY be defined which specify exceptions to the restriction
    on including encapsulated options in an Option Request option.  For
    example, the Option Request option MAY be used to signal support for
    a feature even when that option is encapsulated, as in the case of the
    Prefix Exclude option [RFC6603].  See Table 1."

18. Section 21.11, Authentication Option.  In Figure 22, there is
   "auth-info" at the start of the "authentication information" section.
   I would remove the "auth-info", since this field is actually known
   as "authentication information" in the table below Figure 22.  I
   don't think the "auth-info" label adds any value, and is rather
   inconsistent and might be confusing. 

19. Section 21.14, DISCUSSION, para 1.  Last sentence, RFC references
    have extraneous () around references.

20. Same as #19, para 2.  Replace with "The problem of unused leases can be
    minimized by designing the DHCP service so that only one server responds
    to the Solicit, by using relatively short lifetimes for newly assigned
    leases, or by having DHCP clients release unused leases using the 
    Release message."  Whether or not this paragraph is used, the 
    word "initiatively" isn't commonly used, and some references
    label it "nonstandard" and others show it from the late 1700's.
    I don't think it belongs in an RFC.

20.5 Section 21.16, last sentence.  "Each instance of
     OPTION_VENDOR_CLASS can carry multiple sub-options."  I see
     no sub-options at all here, using the definition of sub-option
     from RFC 7227 (see item #21 for a link to the relevant section
     of this RFC).  I see two possible things that this sentence
     could be trying to say:

     a) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        enterprise-number and vendor-class-data pairs."

     b) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        instances of vendor-class-data, all relating to the same
        enterprise-number."

    I don't know which was intended, if either. Or, possibly, both.
    I know that (b) is true, and I'm pretty sure that (a) is true
    but I could be wrong about that.  If it is true, then it would
    be really good to confirm it here.  This sentence is new since
    RFC 3315.

21. Section 21.17.  This section uses the term "encapsulated options"
    throughout, which I believe is technically incorrect.  See:
    https://tools.ietf.org/html/rfc7227#section-9 
    which explains the distinction between "encapsulated options"
    and "sub-options" really well.  I believe that this section
    should be discussing "sub-options", not "encapsulated options",
    per RFC 7227.   My suggestion would be to rename the "option-data"
    field in Figure 30 as "sub-option-data", to distinguish it from
    the "option-data" field in Figure 31.  And replace the "option-data"
    line in the table after Figure 30 with:

    "sub-option-data    Sub-options, interpreted by vendor-specific
                        code on the clients and servers."
    
    I would replace the paragraph before Figure 31 with:
    "The sub-option-data field MUST be encoded as a sequence of 
    code/length/value fields identical in format to the DHCP 
    options field (see Section 21.1).  The sub-option codes are defined 
    by the vendor identified in the enterprise-number field, and are 
    not managed by IANA.  See Section 9 of [RFC7227].
    Each of the sub-options is formatted as follows:"

    In the table below Figure 31:

    "opt-code           The code for the sub-option.

    option-len          An unsigned integer giving the length of the
                        option-data field in this sub-option in
                        octets.

    option-data         The data area for the sub-option."

    Replace the last line of the para 1 after the table after Figure 31:
    "... MAY contain multiple encapsulated options." -> "... MAY contain
    multiple sub-options."

22. Section 21.21, para 6 after table after Figure 35.  This paragraph
    makes no sense.  In RFC 3633 (the PD RFC), this paragraph talked
    about which numbers to put in T1 and T2.  Now, it talks about
    T1 and T2 "fields" and T1 and T2 "parameters".  The way it comes
    out now, it seems like it is talking about what the *client*
    should be doing with the T1 and T2 fields, not the server.  In
    which case, the sentence should start out "In a message sent
    by a server to a client, the client MUST use..." This is exactly
    what the text in the IA_NA option says, for what that is worth.

    But as it is, it can't be correct.

23. Section 21.22, para 3 after table after Figure 36.  This sentence
    also appears (slightly differently) in Section 21.6, the IA
    Address option.  "A client discards any prefixes for which the
    preferred lifetine is greater than the valid lifetime."  Shouldn't
    this be "A client MUST discard any prefixes..." in both
    sections?  

24. Section 23, para 1, sentence 2.  Replace "of said document" with 
    "of that document".

25. Section 27.1, Normative References.  I think that RFC 7227
    should be normative because if its discussion of the distinction
    between encapsulated options and sub-options in Section 9
    of RFC 7227.

26. Appendix B., Info Refresh Time column.  I don't understand why
    this option is shown for the Inform. message.  I believe that
    the option code for it MUST be in an Option Request option for
    an Inform. message.  But not that the option itself must be in
    the Inform. message, which is what this table is all about.
    Section 21.23 says directly that this option "MUST only appear
    in the top level option area of Reply messages.", so something
    is wrong in one of these places.  I think the table in Appendix
    B is the one that is wrong, and that the * for Info Refresh
    Time should be removed from the row titled Inform.

27. Appendix B., SOL_MAX_RT column.  I believe that the option code
    for the SOL_MAX_RT option MUST appear in an Option Request option
    in a Solicit message, but this table isn't about the Option Request
    option, it is about messages.  So I believe that this is wrong,
    and that the * for SOL_MAX_RT should be removed from the Solicit
    message row.

28. Appendix B., INF_MAX_RT column.  I can see no reason why this is
    listed as an option to appear in the Advertise message.  I think
    this is simply an error and should be removed. 

29. Appendix B. Interesting that the document mentions User Class,
    Vendor Class, and Vendor Specific Options as all valid for
    Relay-Forward and Relay-Reply messages.  I'm not saying that
    isn't OK, but I didn't see anything in this document that would
    suggest anything other than an Interface Id option would go in
    a Relay-Forward or Relay-Reply message.  Maybe I missed it.

30. Appendix C.  This table is only relative to this
    document.  Some of these options can appear in other DHCPv6
    options defined in other RFC's.  That exist today, not just
    future ones.  Perhaps replacing the existing sentence "The
    following ... other options:" with "The following table indicates
    with a "*" where options defined in this document can appear
    in the options field of other options defined in this document.
    Other RFC's define additional situations where options defined
    in this document are encapsulated in other options." would make
    it more clear that this isn't the final word on what options
    can appear inside of what other options.

31. Appendix C.  The sentence describing this table is moderately
    misleading.  "where options can appear in the options field of
    other options." would seem to indicate that the column headings
    along the top of the table are all options.  However, the first
    column isn't the name of an option, it is (presumably) the
    options field of any message.  I think that we should remove
    this column, since any information that it contains is already
    covered (and in more correct detail) by the information in
    Appendix B, which discusses precisely which options can appear
    in the options field of individual messages.  If I'm wrong about
    what the "Option Field" column represents, then it would be
    good to explain it more clearly.

32. Appendix C.  Columns Relay-Forw, Relay-Reply, and Note.
    The note is just wrong, near as I can tell.  There are no
    Relay-Forw or Relay-Reply options.  There are Relay-Forward and
    Relay-Reply messages.  I think having a Relay-Forw and Relay-Reply
    column in this table is very misleading, since as I said above,
    this table seems to be for options.  These aren't options, they
    are messages.   We already have the Relay Message option allowed
    in the Relay-Forward message and Relay-Reply message in Appendix
    B.  In addition, the data there conflicts with the data here
    for the Relay-Forward and Relay-Reply messages.  I don't know
    what someone was trying to communicate here, but I think that we 
    need to remove the Relay-Forw and Relay-Reply columns, and
    the Note.

    I recognize that this is left over from RFC 3315 and wasn't
    something added as part of the current process, but that doesn't
    make it right.

33. Appendix C.  If we remove the first and last two columns, as
    I think makes sense, since this information is already covered
    in Appendix B, we are left with 3 options in the left column
    that have any * in any of the right 4 columns.  Not the end of
    the world, but we could probably explain this with a sentence
    or two.  For instance: "Several options may themselves appear
    in the options field of other options defined in this document.
    The IA Address options may appear in the options field of either
    the Identity Association for Non-temporay Addresses option or
    the Identity Association for Temporary Addresses option.  The
    IA Prefix option may appear in the options field of the Identity
    Association for Prefix Delegation option.  The Status Code
    option may appear in the options field of any of the three
    Identity Association options just discussed."  I have no
    particular preference toward either approach (i.e., keep the
    table or replace it with the above paragraph), but offer the
    paragraph to show one possibility.

Thanks -- Kim

> On May 9, 2017, at 10:52 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hello:
>  
> The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.
>  
> Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!
>  
> Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.
>  
> If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:
>  
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt
>  
> The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98(some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).
>  
> One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.
>  
> The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.
>  
> -          Tomek & Bernie
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 14 Jun 2017 20:13:56 +0000

Jinmei:

We are working to get the -09 version out before the July 3rd IETF-99 cutoff. And, I think we're waiting on text for you regarding one item:

-- start
> it's even more unclear about what these lifetimes are (especially the 
> preferred lifetime).
>

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.
-- end

For reference this is section 21.22 in the -08 version.

And, added a few comments below (BV>) as to actions we did or did not take.

Again, thanks for the suggestions and review!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, June 01, 2017 2:53 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be clear, I'm not requesting sedhcpv6 be specified as *the* authentication protocol in rfc3315bis.  But I'd suggest chairs to explicitly leave notes about the point for security ADs when the doc is sent to the IESG.

BV> We discussed with Ralph and he plans to note it in the shepherd document.

> can't reference that RFC. We documented the reason for this in 

I believe at least the reference to RFC2462 in Section 6.2 is not really appropriate:

Simply because RFC4862 doesn't use the term "stateful address autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862 just replaced it with the term "DHCPv6".  If you want suggested text, my suggestion is simply remove the second half the sentence:

As for the references to RFC2462 due to M/O RA flags, I still think it can be rather misleading.  The sad fact is that M/O flags are dead - all previous attempts at the 6man wg of making them workable failed, and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me newer protocol documents like rfc3315bis still talk about them simply because its predecessor talked about them.

BV> OK, cleaned up text as recommended and there are no more references to 2462.

Section 18
OLD

BV> Used NEW2. There are probably existing implementations that follow the old recommendations.

Section 18
OLD

BV> This second version of the list was removed. I think it was left behind by accident during an editing session.

Section 18.2.1
OLD:

NEW: I actually suggest removing this paragraph.  Especially given M&O flags are "dead", I don't see a strong reason for retaining it in addition to its previous paragraph (which also talks about the delay and for the case of power outage).  If we still want to say something about the interaction with RA, my suggestion is to revise the previous paragraph as follows:

BV> I used this suggested paragraph.

Note that if all of the above suggestions are adopted, there will be no reference to RFC2462.  So you can also remove it from the Refereneces section.

BV> Correct, they are now all gone.

>>>  "no later than" sounds awkward as the lifetime is a duration, not  
>>> a particular point in time.
>

If you want suggestion, this can be fixed easily:
NEW:
 [...] the requesting router MUST set the valid lifetime in those  advertisements to be no larger than the valid lifetime specified in  the IA_PD Prefix option.

i.e., s/later/larger/

BV> Done.

> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly men…

I've already suggested text (I admit the point may be a bit pedantic, though).

BV> We decided to say "global address (including unique local addresses, [RFC4193])" or something very close to that.

Ditto:-)

BV> Done.

>    T1/T2 times associated with any of the client's bindings (earliest

Hmm...this is one of the things why I can't be confident about this spec without actually trying to implement it from the text.  But I don't have enough time to check if the concern is addressed in the entire context, I'll simply give up with it.

BV> We believe we are ok with this as is.

> it's even more unclear about what these lifetimes are (especially the 
> preferred lifetime).
>

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.

BV> See top of the message and main reason for sending it!

[...]

BV> We think we're OK with this as is.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Jun 2017 11:28:43 -0700

At Wed, 14 Jun 2017 20:13:56 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> We are working to get the -09 version out before the July 3rd
> IETF-99 cutoff. And, I think we're waiting on text for you regarding
> one item:

I don't think I promised I would offer text :-) but I admit I should
have provided some followup much earlier.

> > This is not just about wording.  It's about actual protocol
> > behavior, and I don't even know if we have common consensus on it.
> > I also think we can't simply ignore the issue by being silence,
> > since it could result in a bad situation like a site keeps
> > advertising a prefix in RA as a preferred one even when it's
> > already "deprecated" or even "invalidated" in terms of prefix
> > delegation.  I'll see if I can offer something more concrete, but
> > I'd like to raise it as a possible blocking issue.

As I said before (in the quoted text) I actually suspect it's
premature to talk about specific text before discussion.  So let me
talk about what I think is an issue more specifically.

First off, what's this preferred lifetime in the first place?  Section
21.22 simply says:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents
                           infinity.

What does this "recommended" mean?  As far as I can see it's not
explained anywhere else in the draft.  But one possible, or likely,
interpretation would be that it's a recommendation for addresses
configured from this prefix.  More specifically, it would be to use it
as the preferred lifetime of a prefix information option (PIO) of RA
for the delegated prefix (or prefixes derived from the delegated
prefix).  Assuming that, consider some more concrete issue:

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 1 week (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 6 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 6 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

In 3.5 days the PD client starts renewing the prefix.  But, now suppose
this exchange doesn't succeed (even after the client switches to
REBOUND).  Then what should happen in 6 days?  Should the delegated
prefix now be considered "deprecated"?  And what would that mean?
Should the preferred lifetime value of the corresponding RA PIO be
reset to 0 from this point?

And, what if the PD client can't even RENEW/REBOUND until the valid
lifetime expires?  If, like above, the valid lifetime value is copied
from IA_PD prefix to RA PIO, end hosts will have an address with a
pretty large valid lifetime (in this example scenario, at least 6
days) at the time of expiration due to the periodic RA advertisements.
And, even if the advertised PIO valid lifetime is set to 0 at that
point, end clients will still keep using the address for two hours
(see RFC4862).

I actually don't know whether/how existing implementations deal with
cases like this, but I wouldn't be surprised if there are naive
implementation that simply copies the preferred/valid lifetimes from
PD to RA, potentially having the problems described above.  I suspect
we've not heard problem reports in the actual deployment simply
because the lifetimes are sufficiently long compared to possible
network outage periods, and also perhaps because if this problem
happens because the upstream becomes unreachable, then it doesn't
matter much anyway if the end clients keep using "expired" addresses.
Still, as a protocol design I think it's a kind of defect and we
cannot just rely on the operational conditions.

So, can we agree there's a potential problem as some of the
definitions and the usage are not clear enough, aside from whether
that should be addressed in rfc3315bis?

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Jun 2017 11:35:34 -0700

(Sorry, I've noticed a minor but possibly very confusing typo in my
previous message.  I'm replacing the whole text with correcting it
below.  Please ignore the previous one)

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 7 days (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 7 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 7 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

REBOUND).  Then what should happen in 7 days?  Should the delegated

pretty large valid lifetime (in this example scenario, at least 7

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Jun 2017 02:27:39 +0000

Jinmei:

My reaction is you are wrong – the PIO would, whenever sent, be sent with the preferred and valid lifetime REMAINING on the PD lease. So, sure a PIO sent just after the PD lease started would have (close) to the full values, but the values sent an hour later would be 1 hour less than they were.

Thus, I don’t see a problem as the preferred and valid lifetime of the PIO run down as the time of the lease runs down. At T1 (if 50 % of the preferred lifetime), a PIO sent would have ½ preferred lifetime (preferred lifetime – T1) and a valid lifetime of the original valid lifetime – T1.

This is different than if you explicit configured a manual prefix on a router with preferred/valid lifetimes – those would always be advertised in PIOs with the same values. But, when a lease is involved, the values run down and thus the PIO must contain just the remaining times.

Thus, it all works out nicely?

I will take another look at the IAPREFIX preferred/valid lifetime definitions as perhaps we need to tweak them a bit.

- Bernie

On 6/16/17, 2:28 PM, "[email-masked] on behalf of 神明達哉" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    

    
    --
    JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 19 Jun 2017 10:55:08 -0700

At Sat, 17 Jun 2017 02:27:39 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> My reaction is you are wrong – the PIO would, whenever sent, be sent
> with the preferred and valid lifetime REMAINING on the PD lease. So,
> sure a PIO sent just after the PD lease started would have (close)
> to the full values, but the values sent an hour later would be 1
> hour less than they were.

Actually I agreed.  I guess what we're different is the view on how
obvious it is.  I suspect this is not so obvious and there are
actually implementations that can cause the situation where
deprecated/invalidated addresses are used.  There may even be an
implementation that naively copies the lifetimes from PD to RA PIO.

I've monitored RAs advertised in my apartment room.  The ISP is
Comcast and the default router is Apple time capsule.  The lifetimes
advertised in RA PIO are constant and do not decrease as I monitored
it in multiple consecutive RAs.  Of course, it doesn't immediately
mean the time capsule device uses the 'naive' approach.  I actually
don't even know if PD is used or the time capsule is the PD client.
And the time capsule might actually have some safety buffer period and
use a much lower lifetimes for PIO than those provided in PD.  Still,
I think this can be a potential anecdote to suggest there might be a
problematic implementation.

So I don't think it at least doesn't harm if we say that lifetimes of
site addresses derived from the delegated prefix MUST NOT exceed the
remaining time of the lifetimes in the last-received corresponding
PD.  (I don't think we have to specify exactly how to implement this
restriction).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 Jun 2017 18:10:55 +0000

I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie

On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[email-masked]> wrote:

    

    
    --
    JINMEI, Tatuya

---

From: Timothy Winters <[email-masked]>
Date: Mon, 19 Jun 2017 14:32:22 -0400

Hi Bernie,

We have CE Routers that countdown from when the IA_PD is received, and
others that always transmit the lifetime received in the IA_PD in RA
(Always the same).   It's about 50/50 at the moment.   When we were working
on testing for 6024/7084 this was a topic that was discussed but it wasn't
clear answer on what to do with the lifetimes.

You are correct that when the prefix timeout from the IA_PD it will stop
forwarding and transmit a Destination Unreachable message.

Regards,
Tim

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I’ve added Tim Winters as perhaps he can shed some light on this in terms
> of what is tested at the NH Interoperability Lab for PD / CPEs?
>
> Even if a device doesn’t follow this (running down the lifetimes), what’s
> likely to happen when the PD expires is that the traffic will hopefully no
> longer be forwarded by the router (and with a ICMP destination unreachable
> notification) and perhaps RAs will be sent with 0 lifetimes to attempt to
> deprecate the prefix (and any assigned addresses) use as quickly as
> possible?
>
> Ralph or Ole might also have a comment with respect to what they expected
> a requesting router to do based on the original RFC 3633? I don’t think
> this 3315bis document itself caused this potential confusion to exist?
>
> - Bernie
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 Jun 2017 19:27:37 +0000

Thanks Tim. That’s useful, and shows that we do need to be more explicit.

There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and 18.2.10.1) where we have the following text:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the client MUST set the valid lifetime in
      those advertisements to be no later than the valid lifetime
      specified in the IA_PD option.  A client MAY use the preferred
      lifetime specified in the IA_PD option.

The “no later” has been changed to “no larger”. And, actually the IA_PD option is wrong (it should be IAPREFIX option, as that holds the lifetimes).

Perhaps what we really should say is something like:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the valid lifetime in those advertisements
      MUST be no larger than the remaining valid lifetime
      for the delegated prefix.  A client MAY use the preferred
      lifetime as originally received in the IAPREFIX option, provided that whatever
      value is used is less than or equal to the valid lifetime to be sent in the
      router advertisement.

That text doesn’t by itself provide any good way to specify a shorter preferred lifetime so that the prefix is marked deprecated before it becomes invalid, but at least it assures that what is send for the preferred and valid meets the basic requires: preferred <= valid in the RA, and the valid is <= what is specified in the IAPREFIX.

  *   Bernie

From: Timothy Winters <[email-masked]>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <[email-masked]>
Cc: JINMEI Tatuya / 神明達哉 <[email-masked]>, "[email-masked]" <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Hi Bernie,

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.

Regards,
Tim

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

- Bernie

On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[email-masked]<mailto:[email-masked]>> wrote:

    --
    JINMEI, Tatuya

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 24 Jun 2017 21:28:45 +0000

Hi:

Any feedback on this proposed text?

It would be nice to be able to publish an -09 before the 7/3 deadline for IETF-99, and perhaps even send this document on to the IESG (assuming Ralph believes there is consensus to do so).

An alternative, which in retrospect I think I would prefer, would be for the PIO to use the remaining preferred and valid lifetime on the lease and just say that explicitly. That may be cleanest? So, that proposed text would be:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the preferred and valid lifetime in those advertisements
      MUST be no larger than the remaining preferred and valid lifetimes, respectively,
      for the delegated prefix at the time the router advertisement is sent.

Please let me know which of the two versions you’d prefer, or suggest an alternative.

-          Bernie

From: Bernie Volz (volz)
Sent: Monday, June 19, 2017 3:28 PM
To: Timothy Winters <[email-masked]>; JINMEI Tatuya / 神明達哉 <[email-masked]>
Cc: [email-masked]; Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

-          Bernie

From: Timothy Winters <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: JINMEI Tatuya / 神明達哉 <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ralph Droms <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Hi Bernie,

Regards,
Tim

- Bernie

    --
    JINMEI, Tatuya

--

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 Jun 2017 18:15:29 +0000

Hi:

2nd try to see if there’s any comments on this. Trying to close out the -09 version before the IETF-99 deadline (7/3).

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Saturday, June 24, 2017 2:29 PM
To: Timothy Winters <[email-masked]>; JINMEI Tatuya / 神明達哉 <[email-masked]>
Cc: [email-masked]; Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Hi:

-          Bernie

From: Bernie Volz (volz)

-          Bernie

Hi Bernie,

Regards,
Tim

- Bernie

    --
    JINMEI, Tatuya

--

---

From: 神明達哉 <[email-masked]>
Date: Tue, 27 Jun 2017 16:05:00 -0700

At Tue, 27 Jun 2017 18:15:29 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> 2nd try to see if there’s any comments on this. Trying to close out
> the -09 version before the IETF-99 deadline (7/3).

Sorry for the delay, I've been offline.  As for your proposed text:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the preferred and valid lifetime in
      those advertisements MUST be no larger than the remaining
      preferred and valid lifetimes, respectively, for the delegated
      prefix at the time the router advertisement is sent.

it addresses my main concern.  I'd personally generalize it a bit,
though.  For example:

   If the client uses a delegated prefix to configure addresses on
   interfaces on itself or other nodes behind it, the preferred and
   valid lifetimes of those addresses MUST be no larger than the
   remaining preferred and valid lifetimes, respectively, for the
   delegated prefix at any time.  In particular, if the delegated
   prefix or a prefix derived from it is advertised for stateless
   address autoconfiguration [RFC4862], the advertised valid and
   preferred lifetimes MUST NOT exceed the corresponding remaining
   lifetimes of the delegated prefix.

Here I tried to not limit the use of lifetimes to SLAAC (for example,
they could be used in DHCPv6 for the delegated site), while explicitly
noting the SLAAC case as we now know there are implementations that
violate it.

I'd also update the description of the PD 'preferred-lifetime'
(Section 21.22 in the 08 version) from:

to, for example:

      preferred-lifetime   The preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  This lifetime does not affect the
                           protocol behavior of prefix delegation, but
                           has implication on addresses generated
                           using the prefix (see below).  A value of
                           0xFFFFFFFF represents infinity.

Here I avoided the term "recommended" as it's not clear what it means
(I asked this before in this thread but no one answered) and provided
the description of this value I envision.  "see below" refers to the
additional note we're discussing above.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 Jun 2017 23:23:49 +0000

Hi JINMEI:

I like your revised text, “If the client uses a delegated …”.

However, I think I’d like to leave the preferred-lifetime definition as it was (without the “recommended”).

The reason is that:
1. Preferred lifetime does impact the protocol behavior in that it is used to derive the T1/T2 times (for PDs that can be renewed).
2. This also applies to the valid-lifetime; thus, if added should really be in both.
3. The “If the client uses” text is not “below” – that is in 6.3 and 18.2.10.1. I guess for completeness, we might want to reference that. So in 21.22, we could change:

   The values in the preferred and valid lifetimes are the number of
   seconds remaining for each lifetime. Refer to section 18.2.10.1 for
   more details on how these values are used for delegated prefixes.

- Bernie

On 6/27/17, 4:05 PM, "dhcwg on behalf of 神明達哉" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    
    to, for example:

    
    --
    JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 Jun 2017 23:43:36 +0000

FYI – The change can be viewed at:

https://github.com/dhcwg/rfc3315bis/commit/59a134acbbb3e2ad545e3296547707df3d32aecc

- Bernie

On 6/27/17, 4:23 PM, "dhcwg on behalf of Bernie Volz (volz)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi JINMEI:

    
    The reason is that:

    - Bernie

        

        

        

        to, for example:

        
        --
        JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 27 Jun 2017 18:06:10 -0700

At Tue, 27 Jun 2017 23:23:49 +0000,

> as it was (without the “recommended”).

If the awkward "recommended" is removed, it works for me.

--
JINMEI, Tatuya