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

Benjamin Kaduk <kaduk@mit.edu> Sat, 27 February 2021 19:16 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 145953A12C4; Sat, 27 Feb 2021 11:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 KqAsX73p-B48; Sat, 27 Feb 2021 11:16:21 -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 5A8B23A12C3; Sat, 27 Feb 2021 11:16:20 -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 11RJG81u003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 14:16:13 -0500
Date: Sat, 27 Feb 2021 11:16:08 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Fernando Gont <fgont@si6networks.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>
Message-ID: <20210227191608.GG21@kduck.mit.edu>
References: <161411841162.993.9337833948854729986@ietfa.amsl.com> <2f375954-aae1-8089-c59c-f575d2ef8dde@si6networks.com> <20210226022027.GZ21@kduck.mit.edu> <b665b0d5-5cf8-3223-bfe4-77781a3b9e0e@si6networks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b665b0d5-5cf8-3223-bfe4-77781a3b9e0e@si6networks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ksfVeDGc8L-tRLIbpgK6U0wFe-A>
Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-07: (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: Sat, 27 Feb 2021 19:16:23 -0000

On Fri, Feb 26, 2021 at 04:07:56AM -0300, Fernando Gont wrote:
> Hello, Ben,
> 
> On 25/2/21 23:20, Benjamin Kaduk wrote:
> > On Thu, Feb 25, 2021 at 05:27:36PM -0300, Fernando Gont wrote:
> >> Hello, Ben,
> >>
> >> Thanks a lot for our comments! In-line....
> >>
> >> On 23/2/21 19:13, Benjamin Kaduk via Datatracker wrote:
> >> [....]
> >>> Section 3
> [...]
> > 
> > The thread has continued and I think has gotten into enough details that I
> > don't know much about that my insight will not be very valuable.  About the
> > only contribution I might make is that a construction of the form "MUST by
> > default behave such that [list of things] or behave according to RFC 7844"
> > might be a little easier to read, since it's a choice rather than a primary
> > behavior and exception.
> 
> Fair enough.
> 
> I'd suggest something like:
> 
>       o  WPD-10: CE Routers MUST by default use a WAN-side IAID
>          value that is stable between CE Router
>          restarts, DHCPv6 client restarts, or interface state changes
>          (e.g., Transient PPP interfaces), or behave according to
>          [RFC7844].  See Section 3.2 for further details.
> 
> My only concern here is that, in a way, this reads a bit like "pick any 
> of these two behaviors", whereas what we want is something more along 
> the lines of "it MUST do this, unless you implement the anonymity 
> profiles. (i.e., if you pick the RFC7844, it should be because you do 
> mean the CE Router to implement the anonymity profiles).
> 
> 
> 
> So an alternative could be:
> 
>       o  WPD-10: CE Routers MUST by default use a WAN-side IAID
>          value that is stable between CE Router
>          restarts, DHCPv6 client restarts, or interface state changes
>          (e.g., Transient PPP interfaces), unless the CE Router
>          employs [RFC7844] for the WAN-side.  See Section 3.2 for
>          further details.
> 
> (might spell out the title of RFC7844, too....)
> 
> Thoughts? Suggestions?

Those both look good to me, so I expect you'll go with your preference (the
latter).

Thanks,

Ben