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

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD393A0E73 for <dhcwg@ietfa.amsl.com>; Tue, 2 Jun 2020 11:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x7dIV2v4cSE for <dhcwg@ietfa.amsl.com>; Tue, 2 Jun 2020 11:13:00 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868BE3A0E6D for <dhcwg@ietf.org>; Tue, 2 Jun 2020 11:13:00 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id d7so11859701ioq.5 for <dhcwg@ietf.org>; Tue, 02 Jun 2020 11:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zEPNGRivVbds9plHiKXTNoXqZ1vyUAijkxR3WfY4Bwk=; b=RbYVk35LLs4LrnY4ANKQ7ZW2KDDU1+gMXToXIpOJnKAIrzJrpU6IPXv0b2VE/gvDKH QKRb5jo0b8Uoe4bqwWQNtNR379DRJoHmtH/IAdx0UNdM+pUI/YtRKrdQyMCe2TrFgmLn u0oTOAIyVAOLUhYw67kY98bOwgLY9hxxEsimM3q8u1CF6MOvaJEjKdlVzUBh4l/g6PPG KHftCylEwwZ6ll1g04SLaugM4UquvAdAdMVTYXubRjmDq7WK+ezTisMuC5qjC0nCzRx7 o0UBuhgR5f62eFGlGiLb1xE4m4z/M/Inpr39bLYaaAOc+W3LdpLrH26SEbp953kpEQgi hAhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zEPNGRivVbds9plHiKXTNoXqZ1vyUAijkxR3WfY4Bwk=; b=OKJNN6OkN52EFbzxD811kBGvOGS4egjGhwWsUo/9LCq71V/N2grIP3HK3tzAua5zFk kUx5XnJX/g/zLdrASfiQ+IzctJHrobUFgQf7zIZonUYcotiTp+S2ralS7a/ffeozw6np jIcWdc3MPGBFAHcP+Bwm3V3NFh9sIG6CuBS64GJPgE9OAipe+1Ysi5zFImuxkrS3xdJ5 VUJg6J30HllqnOBC5EMRaxdju9pvV/XLIQW9TToy6l3dLMwFxbj8T3RoBrpOSVEbZqCL HFcjzfNDJoXuhO730LPhUodEkTIoSld0Vgbs6SM0q3+V0EHwVm5S4Uhyt1Qbpxm7KyTs 3LTQ==
X-Gm-Message-State: AOAM530lRM+HtNcQwRYtI2fOMvxm9rU0DSYmUgp+p581FmCLavaZBgdZ t7/azCxNCO+YYQvVtrbc6CPsnp3XpMvbzSoG6VaDiw==
X-Google-Smtp-Source: ABdhPJwnuTbrJ2tO2/xJVuHVAitYONxDa2+4Zv8rp3Boh0ONXI0ZtgCvh0LQt50Y5j3+mARMnsJui/Rt9BEXKq1GDJw=
X-Received: by 2002:a05:6602:2e87:: with SMTP id m7mr495939iow.203.1591121579717; Tue, 02 Jun 2020 11:12:59 -0700 (PDT)
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, 2 Jun 2020 20:12:43 +0200
Message-ID: <CALypLp9L_iapcEuYsU3c=Rdu-vc_eULhG_SqEz2r=+u+_w=8DQ@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <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
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 18:13:02 -0000

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
>