Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 28 January 2021 06:54 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7587A3A1334; Wed, 27 Jan 2021 22:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YQjYV5-6Z0t4; Wed, 27 Jan 2021 22:54:56 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFF43A1332; Wed, 27 Jan 2021 22:54:55 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10S6siDU011473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jan 2021 01:54:49 -0500
Date: Wed, 27 Jan 2021 22:54:44 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Fernando Gont <fgont@si6networks.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" <draft-ietf-v6ops-cpe-slaac-renum@ietf.org>, "v6ops-chairs@ietf.org" <v6ops-chairs@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Owen DeLong <owen@delong.com>
Message-ID: <20210128065444.GU21@kduck.mit.edu>
References: <160325603610.17357.6914550111489766157@ietfa.amsl.com> <cf025acf-5192-d9a3-a727-8716d9d7b232@si6networks.com> <4fbc24c6-ef7b-5a99-3d04-69e6c9c3c90a@si6networks.com> <011245F3-558B-4F9D-97E5-56BBEE0419D2@cisco.com> <b9c1e036-399c-e7d4-d46d-ef2f29530e00@si6networks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b9c1e036-399c-e7d4-d46d-ef2f29530e00@si6networks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EaryEUp1TQ48r7V1MMnh1JAY1PY>
Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2021 06:54:58 -0000

Hi Fernando,

On Wed, Jan 27, 2021 at 10:32:54PM -0300, Fernando Gont wrote:
> On 27/1/21 22:15, Bernie Volz (volz) wrote:
> > See comments below (BV>).
> > 
> > - Bernie (from iPad)
> > 
> >> On Jan 27, 2021, at 5:53 PM, Fernando Gont <fgont@si6networks.com> wrote:
> >>
> >> Hi, Ben,
> >>
> >> On 27/1/21 18:21, Fernando Gont wrote:
> >> [....]
> >>>>         *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
> >>>>            lifetimes for any address assignments or prefix delegations for
> >>>>            the deprecated prefixes for at least the valid-lifetime
> >>>>            previously employed for them, or for a period of ND_VALID_LIMIT
> >>>>            if the recommended lifetimes from Section 3.2 are employed.
> >>>>
> >>>> Is it deliberate to say nothing at all about Advertise messages (which
> >>>> are sent in response to Solicit messages, not any of the listed ones)?
> >>> I will double-check this one with my co-authors.
> >>
> >> Our plan is to add this note to the RATIONALE of Section 3.3:
> >>
> >>    The above text does not include responses to DHCPv6 Solicit messages,
> > BV> A Solicit with Rapid Commit may return a Reply. So this only applies to Advertise responses.
> 
> Will fix this. Thanks!
> 
> 
> >>    since Section 18.3.9 of RFC8415 requires that a DHCPv6 server
> >>    that is not going to assign an address or delegated prefix received
> >>    as a hint in the Solicit message MUST NOT include that address or
> >>    delegated prefix in the Advertise message. Additionally, any
> >>    subsequent Solicit messages will trigger the response specified in
> > BV> There are usually no “subsequent” Solicits. There is a subsequent Request.
> 
> Oops. That was just me both sloppy and sleepy..
> 
> The resulting text is:
>     The above text does not include DHCPv6 Advertise messages sent in
>     response to DHCPv6 Solicit messages, since Section 18.3.9 of
>     [RFC8415] requires that a DHCPv6 server
>     that is not going to assign an address or delegated prefix received
>     as a hint in the Solicit message MUST NOT include that address or
>     delegated prefix in the Advertise message. Additionally, any
>     subsequent Request messages will trigger the response specified in
>     this section, and therefore cause the address or prefix to be
>     deprecated.

This definitely addresses my comment, thanks.
Seeing it written out like that does make it seem like it would be a fine
choice to deliberately decide to not say anything about Advertise messages,
since the correct behavior is already required by the combination of what
we do say and the existing specs.  So, please do what you feel is right in
terms of adding this paragraph or leaving it out.

Thank you for working through it with me (and thanks Bernie for helping
out, too)!

-Ben