IETF Logo Mail Archive

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

Nick Hilliard <nick@foobar.org> Mon, 31 July 2017 15:13 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 BCDCA1324C1 for <v6ops@ietfa.amsl.com>; Mon, 31 Jul 2017 08:13:27 -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 Qx0Dieu3mzpH for <v6ops@ietfa.amsl.com>; Mon, 31 Jul 2017 08:13:25 -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 CB36B1324DA for <v6ops@ietf.org>; Mon, 31 Jul 2017 08:13:02 -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 v6VFCwvM016907 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jul 2017 16:12:58 +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: <597F48FA.4000209@foobar.org>
Date: Mon, 31 Jul 2017 16:12:58 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.16 (Macintosh/20170718)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
CC: IPv6 Operations <v6ops@ietf.org>
References: <596CF817.8040900@foobar.org> <CAPt1N1mm6gMEQN0KQ60e=vROOEbooxOBpZEGBm9SGP4WwBDtnw@mail.gmail.com> <596D2E63.3070401@foobar.org> <CAAedzxpT89AYcM6QWq9MHb_dJfeEm7rwpVDunRNUrHah-AhgOw@mail.gmail.com> <596DFD26.4050206@foobar.org> <CAPt1N1kYSj0de_wdiEffNooe2WjVub5wz7kawCNM=MRFa-YsJQ@mail.gmail.com> <596E09CC.3@foobar.org> <CAKD1Yr18nLJhMqzZJcKjrF9FE+ma7jeYNj6cUJfD7pJH8LRtRw@mail.gmail.com>
In-Reply-To: <CAKD1Yr18nLJhMqzZJcKjrF9FE+ma7jeYNj6cUJfD7pJH8LRtRw@mail.gmail.com>
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/oEXKowN7AGNvt37uunbFK1LX31Y>
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: Mon, 31 Jul 2017 15:13:28 -0000

Lorenzo Colitti wrote:
> I think a lot of the disagreement on interpretation is due to the fact
> that some in the discussion (including myself) have inappropriately
> characterized the RFC as recommending against the *use of DHCPv6 in
> general*.

this was the source of the confusion which host-addr-update attempted to
clarify.  As it appears to have been a mistake to start with, the best
thing would be to let draft-hilliard-v6ops-host-addr-update expire.

> It doesn't  - it recommends against *requiring* the use of
> IA_NA / IA_TA in order to use IPv6 on a particular network. I think the
> confusion is limited to this thread though; then RFC itself is pretty clear.

This is a different issue, and it looks like a lot of people on the
v6ops-wg have different interpretations on whether it means this in the
first place.

That said, operators will do what they are going to do and will happily
ignore advice from the IETF if they decide it suits their requirements
better to do that.

Nick

v2.23.0 | Report a Bug | By Email