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

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

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)" <[e-mail] on behalf of [e-mail]> wrote:

    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
        
    
    _______________________________________________
    dhcwg mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dhcwg