Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉 <> Tue, 27 June 2017 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 118A1129B19 for <>; Tue, 27 Jun 2017 16:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fa3eMUN-sM5A for <>; Tue, 27 Jun 2017 16:05:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA53A129B0A for <>; Tue, 27 Jun 2017 16:05:01 -0700 (PDT)
Received: by with SMTP id r62so38112507qkf.0 for <>; Tue, 27 Jun 2017 16:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=UDWNgoUjJqQ7//cqgcS3HpHD2lCH7kAUC0DAVccfAjs=; b=FlXQphyfe5QYT19fGWIjZHP96qRfOGNfyvnga8UixGConJOXbJyPopFBlgdRrFIXxs tyQz4hTdyrpCJ1MK4PrQZ8n2l0bWvG4SMTMENRrhqedZ/2Az+XKH6dLYlcJWK+0gJ6Rf 2epp6qsVOZjWR9pc58QWABRHndPSKcKNOqw6IVFPukK4rISP7aECv1KyUenyiCRfr71g Z7WxqknwtKOl2/FH+HWuVgFuTCLd2d8/Bz1+infzVvZMGjLyF82PbMI5N1PGVDirho2h ugG6ludwMewHzYAvY/8OtXrumCo3RyJ8Cqa92wHkMJgJ61o9qivgt5znYqjKk8yddLk9 6IUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=UDWNgoUjJqQ7//cqgcS3HpHD2lCH7kAUC0DAVccfAjs=; b=RTGcpnckhPCK7yxZ489yf3n6/aLHCUeuQhXiyTMJSzB3Ma58rlTJQ6qZ+kWkJk282q NsZ6LVPDhpVbOj9yl9ITbcupKZtqNr1lqIUH46HSTEwR5fDXcl3u2wvcM021bbQOLkIW gOw65lC6IOCJa9VG4+WaB6hKcFnlMERebEBQaKs+oMYDquWQlm/99r+eXDPAtAwfWA1a /jbHPeZsjvp1cpC2aq1Ytq7XW2N7OJXwEiMFdei/LJcMhf3s5KbUaTbCPELaglpr7Xrn 49KT7qY7hgYSYnfk9svc9N27PQ5XEf0Nreucm37HvVeH3v06IuKgpB2LnaSw/JwgGLII KCEA==
X-Gm-Message-State: AKS2vOwSLliAS3JMPE6KqvHPmHVE+efPzt1DpoPfG0aKiPvgbyi4Wv3g 6BhlUWzl8fYxsoDrna3X7Pt8eMQ1rw==
X-Received: by with SMTP id d11mr10266114qkg.126.1498604700892; Tue, 27 Jun 2017 16:05:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Jun 2017 16:05:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 27 Jun 2017 16:05:00 -0700
X-Google-Sender-Auth: HOZIktYIDiwx-10-6NT2H6n552Y
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: Timothy Winters <>, "" <>, Ralph Droms <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Jun 2017 23:05:04 -0000

At Tue, 27 Jun 2017 18:15:29 +0000,
"Bernie Volz (volz)" <> wrote:

> 2nd try to see if there’s any comments on this. Trying to close out
> the -09 version before the IETF-99 deadline (7/3).

Sorry for the delay, I've been offline.  As for your proposed text:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the preferred and valid lifetime in
      those advertisements MUST be no larger than the remaining
      preferred and valid lifetimes, respectively, for the delegated
      prefix at the time the router advertisement is sent.

it addresses my main concern.  I'd personally generalize it a bit,
though.  For example:

   If the client uses a delegated prefix to configure addresses on
   interfaces on itself or other nodes behind it, the preferred and
   valid lifetimes of those addresses MUST be no larger than the
   remaining preferred and valid lifetimes, respectively, for the
   delegated prefix at any time.  In particular, if the delegated
   prefix or a prefix derived from it is advertised for stateless
   address autoconfiguration [RFC4862], the advertised valid and
   preferred lifetimes MUST NOT exceed the corresponding remaining
   lifetimes of the delegated prefix.

Here I tried to not limit the use of lifetimes to SLAAC (for example,
they could be used in DHCPv6 for the delegated site), while explicitly
noting the SLAAC case as we now know there are implementations that
violate it.

I'd also update the description of the PD 'preferred-lifetime'
(Section 21.22 in the 08 version) from:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents

to, for example:

      preferred-lifetime   The preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  This lifetime does not affect the
                           protocol behavior of prefix delegation, but
                           has implication on addresses generated
                           using the prefix (see below).  A value of
                           0xFFFFFFFF represents infinity.

Here I avoided the term "recommended" as it's not clear what it means
(I asked this before in this thread but no one answered) and provided
the description of this value I envision.  "see below" refers to the
additional note we're discussing above.

JINMEI, Tatuya