Re: [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Tue, 02 June 2020 18:13 UTC

MIME-Version: 1.0
References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> <CALypLp9x1z94bH6mNeZd=UChvkX5W_Xate+M153DWzPaYPHfhw@mail.gmail.com> <CAJE_bqd8a8iqsh0Bu-ZJGDdw=Aadrwng7s9X=qkk9XTJm5LrmQ@mail.gmail.com> <CALypLp-QRYC8Dk--UMg-d0XfUm1RwL4-bwRWWrEUM4SNGcmxZg@mail.gmail.com> <CAJE_bqfLg-6vnw00WUQM=Da-oTxMnV8TQ1coY8=sH925LDCkEQ@mail.gmail.com>
In-Reply-To: <CAJE_bqfLg-6vnw00WUQM=Da-oTxMnV8TQ1coY8=sH925LDCkEQ@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Tue, 02 Jun 2020 20:12:43 +0200
Message-ID: <CALypLp9L_iapcEuYsU3c=Rdu-vc_eULhG_SqEz2r=+u+_w=8DQ@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: dhcwg <dhcwg@ietf.org>, "<int-dir@ietf.org>" <int-dir@ietf.org>, draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008deadd05a71ddc82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/UibF0xo2cHKnXKnP5UoN8sNEwPg>
Subject: Re: [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08
Precedence: list

OK, thanks again for your review!

Carlos

On Tue, Jun 2, 2020 at 8:04 PM 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Tue, 2 Jun 2020 17:40:47 +0200,
> CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> 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
>

[dhcwg] Intdir last call review of draft-ietf-dhc… Tatuya Jinmei via Datatracker
Re: [dhcwg] Intdir last call review of draft-ietf… CARLOS JESUS BERNARDOS CANO
Re: [dhcwg] Intdir last call review of draft-ietf… CARLOS JESUS BERNARDOS CANO
Re: [dhcwg] Intdir last call review of draft-ietf… 神明達哉
Re: [dhcwg] Intdir last call review of draft-ietf… CARLOS JESUS BERNARDOS CANO
Re: [dhcwg] Intdir last call review of draft-ietf… 神明達哉
Re: [dhcwg] Intdir last call review of draft-ietf… CARLOS JESUS BERNARDOS CANO