Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Wed, 21 August 2013 14:21 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F611E80F1 for <dhcwg@ietfa.amsl.com>; Wed, 21 Aug 2013 07:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGlF4+chZer8 for <dhcwg@ietfa.amsl.com>; Wed, 21 Aug 2013 07:21:29 -0700 (PDT)
Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26111E8105 for <dhcwg@ietf.org>; Wed, 21 Aug 2013 07:21:23 -0700 (PDT)
Received: by mail-ea0-f172.google.com with SMTP id r16so267083ead.31 for <dhcwg@ietf.org>; Wed, 21 Aug 2013 07:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oVVWr+1Bi/uq69CwH0ebqdiq/7t8NJrRlhV+nD127jU=; b=BkqyL1bKICf1vFAsNLKIfmfKFk35G7kqqYk9o6vawgNRLgFNRKH213I0KqZDyRogPo mUPIh472aPlizVwlchjQKpn8HGEKmFqOv/U1KfPU6Yl3MI6kI1YTcZtPcMQsDpGJvkRU MzREvZlXcrHYhLnn2mM6deS9n1y3j3xrNyRLvw0uZFtvH0w3gan132uGBIR3FDQMYBjY XX0WBRuCb1png2NEj7dI/9ocX7+j2N9VkAD0FMSk/1q5v6cq5XrKpkzJzrT6XzlGA8KI Vrhk9OMy+d6vCz9z41MFwPBh/nUMXYQ2NdM1GnQ7QAqR3WPQ1JvSlJjnhr6UCTUprEZ7 6Qsg==
X-Received: by 10.15.48.67 with SMTP id g43mr10945390eew.17.1377094881557; Wed, 21 Aug 2013 07:21:21 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id x47sm10131434eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 07:21:20 -0700 (PDT)
Message-ID: <5214CCDC.3090308@gmail.com>
Date: Wed, 21 Aug 2013 16:21:16 +0200
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr>
X-Enigmail-Version: 1.4.6
X-TagToolbar-Keys: D20130821162116244
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 14:21:30 -0000

On 21.08.2013 14:41, mohamed.boucadair@orange.com wrote:
> Hi Tomek,
> 
> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a
> useful feature in order to have more automation and also control
> routes aggregation instead of relying on proprietary behaviors of
> each implementation. Of course, part of these objectives can be
> achieved if routes are installed manually or use an out of band
> mechanism to enforce routing aggregation policies. Still, the
> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because
> the DHCP server has the knowledge of the prefix assignments; and
> therefore routes can be triggered with dhcpv6 .
> 
> A way to progress with this document is to target the Experimental
> track. Based on the experience that will be gained in real
> deployments, the status can be revisited if required.
No, sorry. That won't work. At least not as you'd like it to. Take a
look at IANA registry for DHCPv6 options:
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml.
It clearly states that assigning option codes require experts review
*and* standards action. Experimental drafts are not standards. You are
certainly welcome to proceed with this as experimental, but my
understanding of the process is that it would be published without
options assigned. And the draft (or experimental RFC) without option
code is really useless, because it is unlikely that any verndor would
implement it.

As a side comment, currently assigning the option code for DHCPv6
requires experts review. Let me cite the complete list: Ted Lemon. While
Ted Lemon is certainly a DHCPv6 expert, the standardization process
should not rely on a single person. If Ted becomes unavailable for
whatever reason (e.g. wins a lottery and decides to retire tomorrow on
his private island), we wouldn't get new DHCPv6 options any more.

I suppose that is something that should be corrected one day, probably
together with the registry name.

Tomek