IETF Logo Mail Archive

Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt

otroan@employees.org Mon, 02 November 2020 13:50 UTC

Return-Path: <otroan@employees.org>
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 229FE3A0FFA for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 05:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PkIUDB9Y64W2 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 05:50:03 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003493A0FF6 for <v6ops@ietf.org>; Mon, 2 Nov 2020 05:50:02 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2001:420:44c1:1250:107d:ab32:eb22:a23d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id EEEDE4E11ADB; Mon, 2 Nov 2020 13:50:01 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5BA8D42FB94C; Mon, 2 Nov 2020 14:49:59 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: otroan@employees.org
In-Reply-To: <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com>
Date: Mon, 02 Nov 2020 14:49:59 +0100
Cc: Lorenzo Colitti <lorenzo@google.com>, Naveen Kottapalli <nkottapalli@benu.net>, Dmytro Shytyi <dmytro.shytyi@sfr.com>, IPv6 Operations <v6ops@ietf.org>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9B8FDDC-01B0-4523-99AC-47A6868767F1@employees.org>
References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <CAJhXr98mPsopQrUiKfXGuN+wxSEtNiP00LBEGrYObz62FHSa_Q@mail.gmail.com> <CABNhwV1LTcVKobDpiEjnxqKbX9drz1od+RNg7EdX_WO04JQgUw@mail.gmail.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <CAKD1Yr2tUg7GZcne1SkgZZYHJ3Prr=F3hMRDTAZ2=H+UgK2FWg@mail.gmail.com> <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1pj6LZJOiYrBotnLav1rR7kdGXs>
Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
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: Mon, 02 Nov 2020 13:50:04 -0000

>> AFAICS this is a straight violation of the text in RFC 4291 which says that interface IDs are 64 bits long. As such, I don't see the point in discussing it unless there is reason to believe that that text will change.
> 
> I'm not disputing the point. My question is a little different, though. If we preclude discussion on the basis that one of the tablets brought down the mountain has different words chiseled into it, we preclude operational input to it - and if it solves an operational problem, we kill that solution. My question is: do we see a problem that might argue for 4291's specification to change?
> 
> Absent a problem, we don't need a solution, and that might be an important data point to 6man.

Changing the 64 bit boundary is a solution.
Permissionless extension of the network is a problem (one mentioned in the draft).

While the draft has a particular solution in mind, I wouldn't mind discussing the problems the draft enumerates.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email