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

Ole Troan <otroan@employees.org> Fri, 10 November 2017 21:45 UTC

Return-Path: <otroan@employees.org>
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 D765A1294B2; Fri, 10 Nov 2017 13:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qim6zaULi_jI; Fri, 10 Nov 2017 13:45:52 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDA0126BF3; Fri, 10 Nov 2017 13:45:52 -0800 (PST)
Received: from h.hanazo.no (dhcp-9788.meeting.ietf.org [31.133.151.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 476032D4F99; Fri, 10 Nov 2017 21:45:51 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8B1FA200BA6881; Sat, 11 Nov 2017 05:45:38 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <C5C1A9B5-389A-47CE-AD5C-B1D5C97DB995@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_E7D7C374-6759-4DF2-A43F-885B6327E922"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 05:45:37 +0800
In-Reply-To: <e7465ac9-731f-f41b-c240-f2d9fd6e3c59@si6networks.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont <fgont@si6networks.com>
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> <e7465ac9-731f-f41b-c240-f2d9fd6e3c59@si6networks.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SIZIgggbsVOxchsrXqu0N8i3l5A>
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: Fri, 10 Nov 2017 21:45:54 -0000

Fernando,

> On 11 Nov 2017, at 05:04, Fernando Gont <fgont@si6networks.com>; wrote:
> 
> On 11/10/2017 05:42 PM, Ole Troan 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.
> 
> How do you get from this: "it only requires implementation change on one
> 'side' of the protocol" to this: "From that perspective I think you can
> argue that this is not a protocol specification". (First sentence
> acknowledges it *is* a protocol)

For it to be a new protocol (or protocol change, it requires _two_ or more communicating entities to be updated.
(The reference above was to the ND/SLAAC protocol.)
Proven by the fact that the host does not change, it doesn't change the ND protocol.
(With the set of reservations outlines in previous email).

Cheers,
Ole