Re: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption**

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 20 February 2020 12:54 UTC

Return-Path: <swmike@swm.pp.se>
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 B9FB112001A for <v6ops@ietfa.amsl.com>; Thu, 20 Feb 2020 04:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=swm.pp.se
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 QDl2w-Zy_L4N for <v6ops@ietfa.amsl.com>; Thu, 20 Feb 2020 04:54:09 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 825331200EF for <v6ops@ietf.org>; Thu, 20 Feb 2020 04:54:09 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 64296B3; Thu, 20 Feb 2020 13:54:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1582203246; bh=DjCrZWgvsWEs1Wz2ScpgXmF4AIAkTqybYcoLF+o66pw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3EOLDxIimzuy2uNMIFxGf2N7/Y60Ycdw+9EXmLzYl3bjZJkHytan1UGRQvY95/zJ7 ovusmsRIBI03MjG3r43a19H0c5yghTr0QVdYHpzzaJmJio6tOrg0xXJhsLfF3JsOTa SnELkSgMeJ+eyw9/7SqwAPQg95JXoho8ZWjfx2eI=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5DBFDB2; Thu, 20 Feb 2020 13:54:06 +0100 (CET)
Date: Thu, 20 Feb 2020 13:54:06 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Fernando Gont <fgont@si6networks.com>
cc: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <38434b0a-f50b-b8fc-be8f-404c889a756e@si6networks.com>
Message-ID: <alpine.DEB.2.20.2002201345000.4069@uplift.swm.pp.se>
References: <BN7PR05MB3938CECFE3021577A57783D2AE3A0@BN7PR05MB3938.namprd05.prod.outlook.com> <alpine.DEB.2.20.2002101325370.8336@uplift.swm.pp.se> <250c5eae-07c3-6b30-f2e0-4c69ff1bea2c@si6networks.com> <alpine.DEB.2.20.2002200804360.4069@uplift.swm.pp.se> <fe636e34-3a8f-1a80-50e2-21bd135b54b5@si6networks.com> <alpine.DEB.2.20.2002201157000.4069@uplift.swm.pp.se> <38434b0a-f50b-b8fc-be8f-404c889a756e@si6networks.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-3-_e7lodXoVm-9j3_NKPzJNziI>
Subject: Re: [v6ops] draft-gont-v6ops-cpe-slaac-renum **Call for Adoption**
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, 20 Feb 2020 12:54:12 -0000

On Thu, 20 Feb 2020, Fernando Gont wrote:

> Point taken. How about:
> 'Any prefixes that were previously advertised via PIOs in Router 
> Advertisement (RA) messages, and that have become stale, should be advertised 
> with a PIOs that have both the "Valid Lifetime" and the "Preferred Lifetime" 
> set to 0, and the A/L flags with the same settings as in the previous RA 
> messages'
>
>
> Not sure if "with the same settings" is clear enough, though.

"unchanged"?

> Agreed. Although L-13 of RFC7084 makes the reader assume what the proper 
> settings for the flags are.

The longer I participate in the IETF, the more I adopt the opinion that 
documents should not be overly prescriptive.

Is there some text on *why* we're doing this? Perhaps that's better 
instead of writing exactly what the flags should be etc?

Perhaps write that Valid/Preferred lifetime should become zero so that new 
client connections are not sourced from these IPs? Isn't the most 
important thing that the Preferred lifetime is this way? Perhaps write 
"SHOULD NOT change any other flags in the PIO"?

L-13 also has text regarding 2 hour and "whatever is lower". I seem to 
remember this was because some other RFC said something about 2 hour 
minimum... is this still true?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se