Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Nick Hilliard <nick@foobar.org> Fri, 24 February 2017 15:11 UTC

Return-Path: <nick@foobar.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 29BF2129C51; Fri, 24 Feb 2017 07:11:23 -0800 (PST)
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 hGQNah6_REZG; Fri, 24 Feb 2017 07:11:21 -0800 (PST)
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 0F06B1296C1; Fri, 24 Feb 2017 07:11:20 -0800 (PST)
X-Envelope-To: 6man-chairs@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 v1OFBHQK043985 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2017 15:11:18 GMT (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: <58B04D15.7030506@foobar.org>
Date: Fri, 24 Feb 2017 15:11:17 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.10 (Macintosh/20170123)
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
References: <20170221001940.GB84656@Vurt.local> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <7960ff2d-359f-429c-6e82-ef592f90bf53@gmail.com> <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com> <5ce34926-6bde-6410-9b1e-3f61e48e9a1d@gmail.com> <CAKD1Yr1yRTUPVTTicaTkA8fAFxHiHxdLG8ZzEHjCUDDzKg5zJg@mail.gmail.com> <CAN-Dau0xpjB4Z8CgSfW0W7y4F_wnXNS+Ws1UNBC-YnBDrPiTjQ@mail.gmail.com> <cf3496dc-47c6-6c6b-a42a-e0402789110a@si6networks.com> <CAN-Dau3bHXOaJGe1UaLdDht9=+WiD4SEu8qw9Sc915tOes5seA@mail.gmail.com> <A0EDE3AA-95AA-418B-A2B3-E9C8A74204A5@darou.fr> <alpine.DEB.2.02.1702241423100.15705@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1702241423100.15705@uplift.swm.pp.se>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/E_AujC9ZlOXHsZCBUfWhjnGs5Os>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 24 Feb 2017 15:11:23 -0000

Mikael Abrahamsson wrote:
> I just want to state my opinion that whatever text we come up with should
> reflect current operational reality, in that SLAAC A=1 only works on /64,
> and that people use all kinds of subnet sizes when manually configuring
> interfaces.
> 
> If current code doesn't treat 000::/3 in any special case, then documents
> should reflect this.
> 
> Mandating /64 only for any IPv6 use case doesn't reflect reality as I see
> it. I don't want to see A=1 /64 SLAAC requirement relaxed either.
> 
> I just want the -bis document to reflect what is currently in the field
> and we know works. Nothing more, nothing less.

I wholly agree with this as it applies to draft-ietf-6man-rfc4291bis.

As a general comment, it should be reiterated that operational feedback
is critical to standards development and that if field deployment issues
are neglected, this damages the standards development process.  It would
be unfortunate if this document fell prey to this folly.

Nick