IETF Logo Mail Archive

Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

heasley <heas@shrubbery.net> Fri, 24 February 2017 16:24 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89791299AE; Fri, 24 Feb 2017 08:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 VAoWXPWu_RZi; Fri, 24 Feb 2017 08:24:08 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7212988C; Fri, 24 Feb 2017 08:24:08 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 0EBD14D9AD; Fri, 24 Feb 2017 16:24:08 +0000 (UTC)
Date: Fri, 24 Feb 2017 16:24:08 +0000
From: heasley <heas@shrubbery.net>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
Message-ID: <20170224162408.GD93870@shrubbery.net>
References: <58AF313D.3020905@foobar.org> <CAO42Z2ymnLm9dUNL3doU9+vR0eMzGbr71HQybbibXq9rCObP3A@mail.gmail.com> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> <20170224075940.GW2367@Space.Net> <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BHCTJA9ZNikkK6EwxvGsYNGbuH4>
Cc: IPv6 Operations <v6ops@ietf.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 16:24:09 -0000

Fri, Feb 24, 2017 at 09:12:45AM +0100, JORDI PALET MARTINEZ:
> So, are we spending too much time in this and is not really necessary?
> 
> Can we live with the actual text with has been in the market, and working well, for “x” years?
> 
> Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x” years and “n” verified implementations, before we move to STD? If the answer is no, is the balance between living with the current text but moving to STD a better option than waiting for “x” years again?

I prefer the document is fixed now; start the process of fixing classful
implementations now, rather than in x years - or please save operators from
those x+ years of pain.

v2.23.0 | Report a Bug | By Email