Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Warren Kumari <warren@kumari.net> Sat, 11 November 2017 09:35 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2814129480 for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2017 01:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 fMS_OhL8T_yu for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2017 01:34:59 -0800 (PST)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCD7129449 for <6man@ietf.org>; Sat, 11 Nov 2017 01:34:58 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id l8so10462112wre.12 for <6man@ietf.org>; Sat, 11 Nov 2017 01:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vDSVcKrVeTZj4Q0btSR3Qv2J/+IE5HjFTCfDx3WDwL4=; b=kz5odJ4glnS/sKVcHsGv7PAoI31KZuwsj1WObWyAUPkBT1in1eOBpa+0wZYR4I/snz t9WzMOrRa0xB0ycGvjXljsWEXuB1/Ellq3oM0JZeQPYVNiKUfiE9LLO12UMva42mXtzF /wysDoQrJ1DSNOGvXUYbt45Xb+uQXccVN2x1VpnDEpU/KprKoAp+pBTtSlA+v3KSweHa lehfPzPf5RW3myuXbLm2zlOTwHHaklQR8EGX5Uj58wRIWYRP2HlaN5rrxxHKopkhjZsJ JZmnanYYLYm+vMzehlgdKYpi3OEqX7PkRjjD//58rnWWZpy2AgJ3DqBFiEG+/oCAFtbe 42iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vDSVcKrVeTZj4Q0btSR3Qv2J/+IE5HjFTCfDx3WDwL4=; b=EGiwZSdrF/z6gqIg5YIJuaVC6k3+ahL+KIKx++mYv2i7biszc7nG36teJK2wUaIZR8 k/yoL2ZIVps4GGfn4OoGzRcnaf/vt+8qmD4jbQaL6uiNEYK6j3C7F1DxTDY0NSi2pR2P YWagdh2De8CyVUGFa2n/rMUFxPU3WdUq/xwL2tHYK1kj7kZpamPNO2nomrNm1cpbJrjp KsvIWLSAKJ7afiEmm9YNI77DhNe1/L3RgkcoHAnTNQb4wQyvAey6jG6czhlOhzf6J+vL PfsibzmX1GgGokxIXNujJCRzjQsSlY2NLMw6tmhbOsF/K9ztycPLcd9u/9+0xMNStfiO UD5w==
X-Gm-Message-State: AJaThX5KJFL9zNq9jletTZvljtQfZ44TmIT+bHM0TOMjxLBeC5JDfNfQ 7jvzFYuGZVWokicUt8h7uALlVu+k4L3dDpoIA1dMZw==
X-Google-Smtp-Source: AGs4zMYjhXB4MosdHyBNiH0jJM8lDQR9FSuOEili1wJw0ZVgqGc9aVokTcMeJIxDLaduPhm2XhGYhHVc/juCnhIbXU0=
X-Received: by 10.223.151.212 with SMTP id t20mr2593184wrb.2.1510392896813; Sat, 11 Nov 2017 01:34:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Sat, 11 Nov 2017 01:34:15 -0800 (PST)
In-Reply-To: <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 11 Nov 2017 17:34:15 +0800
Message-ID: <CAHw9_iLoT-HWbO=iYzNseU6+DXd4iY4odsBKJNN9nyi3pKY1uQ@mail.gmail.com>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan <otroan@employees.org>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/o1-MBxRKEnSjLMxt6wntOBBpWVY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2017 09:35:01 -0000

On Sat, Nov 11, 2017 at 4:42 AM, Ole Troan <otroan@employees.org> wrote:
>> 1) My comment to the list was essentially arguing that this document
>> contains a protocol specification, and such part is not suitable. I
>> think it should be easy to converge on something regarding this one:
>>
>> Can anyone (you, for instance), provide a definition of what is a
>> protocol, and the run this document through such definition and figure
>> out if it fits or it doesn't?
>
>
> A protocol is a system of rules that allow _two_ or more nodes to communicate.
> The protocol specifies the syntax, semantics and so on (1).
>
> A protocol specification does not specify only the wire format.
>
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor its semantics.
> It only requires implementation change on one 'side' of the protocol, namely on the routers.
> From that perspective I think you can argue that this is not a protocol specification.
>
> I think you also make a point that there are further considerations here, than just the wire-format. Especially around additional state in the routers. In the early days of IPv6 design a lot of time and effort was made in avoiding state in the network. If this mechanism made address allocation inherently less robust, I think a case could be made for why the IETF should specify this in more detail.
> I am not convinced of that though. (In my implementation per host prefix adds configured state, but dramatically lessens dynamic state (ND)).
>
> Interesting question.
>
> Cheers,
> Ole
>
> PS: This draft also raises some interesting IETF process issues around change control, oversight and how involved the working group should be in changes happening after the document is handed over to the IESG.

Yup, that is always a tension.

In this particular case, there was an IETF LC on May 23rd, completing
June 6. There were a number of comments addressed and it went through
IESG review / telechat on Aug 17 telechat (as version -07).

There were enough issues raised during the IESG eval (and continuing
discussion on the V6OPS list exposing lack of clarity) that I decided
to return it to the WG on Sept 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg27681.html)

The text under discussion was added in version -09 (Sept 14th).
There was a second WGLC (on version -12) on Oct 1st
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28048.html)
which completed Oct 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28062.html).

I decided that the changes were sufficently small that it did not need
a second IETF LC (this may have been a mistake), and it had a second
IESG review / was on the October 12th telechat (as version -12).

How involved the WG should be after handing it to the IESG is always
tricky, but in this particular case the document was with the WG when
this text was added (which I think is fine).


W
>
> 1:Freely borrowed from wikipedia.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf