Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Fernando,

On Wed, Jan 27, 2021 at 10:32:54PM -0300, Fernando Gont wrote:
> On 27/1/21 22:15, Bernie Volz (volz) wrote:
> > See comments below (BV>).
> > 
> > - Bernie (from iPad)
> > 
> >> On Jan 27, 2021, at 5:53 PM, Fernando Gont <[e-mail]> wrote:
> >>
> >> Hi, Ben,
> >>
> >> On 27/1/21 18:21, Fernando Gont wrote:
> >> [....]
> >>>>         *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
> >>>>            lifetimes for any address assignments or prefix delegations for
> >>>>            the deprecated prefixes for at least the valid-lifetime
> >>>>            previously employed for them, or for a period of ND_VALID_LIMIT
> >>>>            if the recommended lifetimes from Section 3.2 are employed.
> >>>>
> >>>> Is it deliberate to say nothing at all about Advertise messages (which
> >>>> are sent in response to Solicit messages, not any of the listed ones)?
> >>> I will double-check this one with my co-authors.
> >>
> >> Our plan is to add this note to the RATIONALE of Section 3.3:
> >>
> >>    The above text does not include responses to DHCPv6 Solicit messages,
> > BV> A Solicit with Rapid Commit may return a Reply. So this only applies to Advertise responses.
> 
> Will fix this. Thanks!
> 
> 
> >>    since Section 18.3.9 of RFC8415 requires that a DHCPv6 server
> >>    that is not going to assign an address or delegated prefix received
> >>    as a hint in the Solicit message MUST NOT include that address or
> >>    delegated prefix in the Advertise message. Additionally, any
> >>    subsequent Solicit messages will trigger the response specified in
> > BV> There are usually no “subsequent” Solicits. There is a subsequent Request.
> 
> Oops. That was just me both sloppy and sleepy..
> 
> The resulting text is:
>     The above text does not include DHCPv6 Advertise messages sent in
>     response to DHCPv6 Solicit messages, since Section 18.3.9 of
>     [RFC8415] requires that a DHCPv6 server
>     that is not going to assign an address or delegated prefix received
>     as a hint in the Solicit message MUST NOT include that address or
>     delegated prefix in the Advertise message. Additionally, any
>     subsequent Request messages will trigger the response specified in
>     this section, and therefore cause the address or prefix to be
>     deprecated.

This definitely addresses my comment, thanks.
Seeing it written out like that does make it seem like it would be a fine
choice to deliberately decide to not say anything about Advertise messages,
since the correct behavior is already required by the combination of what
we do say and the existing specs.  So, please do what you feel is right in
terms of adding this paragraph or leaving it out.

Thank you for working through it with me (and thanks Bernie for helping
out, too)!

-Ben