OK, thanks again for your review!
Carlos
On Tue, Jun 2, 2020 at 8:04 PM 神明達哉 <jinmei@xxxxxxxxxx> wrote:
At Tue, 2 Jun 2020 17:40:47 +0200,
CARLOS JESUS BERNARDOS CANO <cjbc@xxxxxxxxxx> wrote:
> > > > It's not clear to me what 'the preferred quadrants are known for the
> > > > allocation of any "new" addresses' means. Does this mean the server
> > > > will assign a new address from the specified quadrant(s) in response
> > > > to the Renew in this situation?
> > >
> > > [Carlos] Yes. If the currently assigned addresses cannot be renewed, then
> > > the server will try to allocate different (that's what "new" means)
> > > addresses from the same quadrant. We have added "different" to the text
> > in
> > > version -09 to make this clearer.
> >
> > Hmm, isn't it different from what the server would do with Renew for
> > other types of IAs? (Assuming that's correct) being different itself
> > isn't necessarily wrong, but in that case I'd like to see an
> > explanation on why it differs.
> >
>
> [Carlos] Not sure if I got your point. Do you refer to adding an
> explanation of why the server might not be able to renew the addresses that
> the client is using? Because this might be for different operational
> reasons (like it might happen with IP addresses for example).
I thought the server doesn't make a new assignment for IA_NA or IA_PD
when the server finds the lifetimes of the currently (IPv6) address or
prefix cannot be extended. And I thought this specification somehow
deliberately differs from these cases. But on re-reading RFC8415 I've
noticed this:
The server may choose to change the list of addresses or delegated
prefixes and the lifetimes in IAs that are returned to the client.
It doesn't seem to discuss the implication of being unable to extend
the lifetimes regarding this behavior, but I now see that assigning a
different resource (IPv6 address or prefix, or in this draft's case,
L2 address) in response to Renew.
So please simply ignore this comment.
--
JINMEI, Tatuya
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
