IETF Logo Mail Archive

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

神明達哉 <jinmei@wide.ad.jp> Tue, 02 June 2020 18:04 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 6A47B3A0E16; Tue, 2 Jun 2020 11:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 U34LddXKStQk; Tue, 2 Jun 2020 11:04:41 -0700 (PDT)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 636093A0EA6; Tue, 2 Jun 2020 11:04:38 -0700 (PDT)
Received: by mail-wr1-f47.google.com with SMTP id h5so4326461wrc.7; Tue, 02 Jun 2020 11:04:38 -0700 (PDT)
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=xXhgF/BeeFMaMvT2F2aUVL2rBvW8rhtJ4kv2pSw6uhE=; b=WwnULVEuNS9WW/1Fzr4CyTLLteNAxUKggsy/cgxpiBTv5XiDfbjmIIVHqjfAIunKpt jISRAhjW29T2V3dQXgLoCjitZF/AfhvEUHtlh8OsAqvCMivGj2IPxwtfRbID+cd+y4fh s66vdjHMjNhPZfPM2JHLdp9ZwPJyhm+MsosrFXHs63xFLBC0oZsLuGSxAfUxpC+P9Uqe 84SCgL+WnEuR/L3oYzZ7rGRzAOSRAm1FbP45Xld/NEQiU6NaaasGm8QrL3IKZ7GIL2dq UKmFw1x9ZcOX9DBS694krFinD4Dne8fycxEkXqV+kG7Ys8q8DGf9oELsRwzOJT/aTC5x 6+WQ==
X-Gm-Message-State: AOAM5311VADBL3nj6CKjhHqgmcJZS0kLfDwMR8p9xnf8Vr4t8/s3uWA3 vyKviYmBS+PD+qWrVWyzoLUjAYcJs8ojBiauVUQ=
X-Google-Smtp-Source: ABdhPJxqIsWovvGZSs0l/MxpRDcIZ7/YJLtbZeAI//UvuHke837hWo2uoXllkWLUPvTr9Vgnv9iJcbM8ilmEAEKYGDU=
X-Received: by 2002:adf:e749:: with SMTP id c9mr29719446wrn.25.1591121076756; Tue, 02 Jun 2020 11:04:36 -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>
In-Reply-To: <CALypLp-QRYC8Dk--UMg-d0XfUm1RwL4-bwRWWrEUM4SNGcmxZg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 02 Jun 2020 11:04:24 -0700
Message-ID: <CAJE_bqfLg-6vnw00WUQM=Da-oTxMnV8TQ1coY8=sH925LDCkEQ@mail.gmail.com>
To: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
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: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ZiA9fkES0pQ9ag_a5v1U23uNSbw>
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:04:45 -0000

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

v2.23.0 | Report a Bug | By Email