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

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

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 神明達哉" <[e-mail] on behalf of [e-mail]> wrote:

    At Tue, 27 Jun 2017 18:15:29 +0000,
    "Bernie Volz (volz)" <[e-mail]> 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:
    
          preferred-lifetime   The recommended preferred lifetime for the
                               prefix in the option, expressed in units of
                               seconds.  A value of 0xFFFFFFFF represents
                               infinity.
    
    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
    
    _______________________________________________
    dhcwg mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dhcwg