Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

Nick Hilliard <nick@foobar.org> Tue, 18 July 2017 12:16 UTC

Return-Path: <nick@foobar.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 E37F4131461 for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 05:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 T6IOK9rPoBcC for <v6ops@ietfa.amsl.com>; Tue, 18 Jul 2017 05:16:58 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3351127599 for <v6ops@ietf.org>; Tue, 18 Jul 2017 05:16:57 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6ICGrfM014117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 13:16:53 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <596DFC35.7080509@foobar.org>
Date: Tue, 18 Jul 2017 13:16:53 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.15 (Macintosh/20170609)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Mark Smith <markzzzsmith@gmail.com>, IPv6 Operations <v6ops@ietf.org>
References: <596CF817.8040900@foobar.org> <CAO42Z2wFSXWru_Tgwpuf2xgOCr2iX0BwrTHvnS2TcR6EQBi1Fw@mail.gmail.com> <CAPt1N1mO+kHtVd++bxzhBFMiC6bWhrbREq=M_Qck0Mp=-VHSFg@mail.gmail.com>
In-Reply-To: <CAPt1N1mO+kHtVd++bxzhBFMiC6bWhrbREq=M_Qck0Mp=-VHSFg@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Yuh_GQvufOCPQGAfXXGFs-WYdHk>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 18 Jul 2017 12:17:00 -0000

Ted Lemon wrote:
> Yeah, a couple of reminders here.  First, the text in the RFC is
> explicitly recommending the use of IA_PD as the _only_ solution to
> delegating prefixes.

Which is problematic because there was no consensus that I could see
during the discussion phase of draft-ietf-v6ops-host-addr-availability
that there was widespread use of DHCPv6-PD as a means of satisfying the
aims providing extra addresses for end hosts (as opposed to delegating
them to routers, which is a different issue entirely).  The lack of
consensus was remarked on at the time.  It seems extraordinary that this
also ended up

> Second, this is an RFC, and the document that
> proposes a way to delegate prefixes without DHCP is a draft, not an RFC.
>   That document is not mentioned in the RFC.   So to suggest that this
> document says that IETF consensus is that DHCP is NOT RECOMMENDED is
> simply incorrect.​

The interpretation of the principal author of BCP206 is diametrically
opposite on this point.

If there are polar opposite views in v6ops on how BCP206 should be
interpreted, this suggests that there is an ambiguity in the document.
If people in v6ops-wg cannot agree on what the document means, what hope
does anyone else have in interpreting it?

Nick