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

Nick Hilliard <nick@foobar.org> Mon, 17 July 2017 17:47 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 94AF012F4B2 for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 10:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 vtyvpnq6IRhb for <v6ops@ietfa.amsl.com>; Mon, 17 Jul 2017 10:47:07 -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 71ECE1289B0 for <v6ops@ietf.org>; Mon, 17 Jul 2017 10:47:07 -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 v6HHl3pi075374 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for <v6ops@ietf.org>; Mon, 17 Jul 2017 18:47:04 +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: <596CF817.8040900@foobar.org>
Date: Mon, 17 Jul 2017 18:47:03 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.15 (Macintosh/20170609)
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5x3eUTkXR0lAdxoBf_ktUqhWgTE>
Subject: [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: Mon, 17 Jul 2017 17:47:09 -0000

draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.

It has recently been claimed that IETF best current practice is that
DHCPv6 is not recommended due to the recommendations section in
RFC7934/BCP204.

The relevant text was slipped into
draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
days before the document went into IETF LC.  There was no discussion
about this text change either in the v6ops working group or at IETF
review or IESG level: perhaps the modification appeared innocuous or
maybe it just wasn't not noticed.

Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)

This presents a variety of problems, the most serious of which are 1)
that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
without extensive discussion or debate about this particular issue at
the relevant working group, and ignores the both the widespread use of
the protocol and its active development at the ietf, and 2) that a
change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
in the IPv6 host specification.

Job and I believe that this went through by mistake and that if the WG
had noticed the change at the time, consensus would never have been
reached on what is a serious semantic change to IETF lore.

Right now, the most prudent course of action would be to roll back the
change until a proper debate has been had.  We invite WG comments on
this doc.

Nick

internet-drafts@ietf.org wrote:
> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> has been successfully submitted by Nick Hilliard and posted to the
> IETF repository.
> 
> Name:		draft-hilliard-v6ops-host-addr-update
> Revision:	00
> Title:		Update for IPv6 Host Address Availability Recommendations
> Document date:	2017-07-17
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
> Htmlized:       https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00
> 
> 
> Abstract:
>    The IPv6 Host Address Availability Recommendations Best Current
>    Practice (RFC 7934), describes why IPv6 hosts should use multiple
>    global addresses when attaching to a network.  This document updates
>    RFC 7934 by removing a recommendation for networks to give the host
>    the ability to use new addresses without requiring explicit requests.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>