Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

Ca By <cb.list6@gmail.com> Wed, 07 June 2017 22:41 UTC

Return-Path: <cb.list6@gmail.com>
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 4292F1271FD for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 15:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Di1u25xjLior for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 15:41:30 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324AC1270A7 for <ipv6@ietf.org>; Wed, 7 Jun 2017 15:41:30 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id l75so8035666ywc.3 for <ipv6@ietf.org>; Wed, 07 Jun 2017 15:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fclpym6arLY/Ft2y9nKwvutLQCbNueIEQGGKalBqmhg=; b=VnBBiqt8bMIT1+CA/bbdoQ/kRkgR5Cdj8JPOR+cGQbefOxM5WS1UDcbDwYFJVEBqBT FdczDTekkUvD5sZPWS2jF9ptD4iCmCw/UqGdrul6yMOaES8SUf5j5WeYDbgXbdVBu1po SfJnWOqzSTGYjWs1lSiACXk4uN785e5p6y8lFMdIvCjG1vMSEUtJC4zmoC9WwoOjzatI QX6gwbPBQTcOZSgK5qOpLphaMGKlkmvmy+CDFA1FLt1zSAE0HcY1uH8uquvtDE7SGf+W LDNAEZxCx1ZE7srEatsqJSqV/kM95UBbYhqKU1xkw0HCQ9SKH7eN6GEb96WSd3NxJpEM r4Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fclpym6arLY/Ft2y9nKwvutLQCbNueIEQGGKalBqmhg=; b=jIBOtuAqg+LZ8bGtzRQimz7bbQUjOsqUjj1nNwcCpmTs69F+kwpfBkMV92FI9iN/Jl t9kvCDCKzmzuDQzG+NMtwgFIR4+/cR8C4mqcwk4Lp5PISoiGgLlHjZsfNcc3DOpECq0X fmdr/LmYqEXREjWTlW3FaUvy23GO6MCDmb2QF5FcA0RfwbxiKYE9g/z+zKYOJgrpYRiz 1ums9cN6LLzLqkFptC4Mi/fW6ZDtBJx9qGuzCvgrzRhuYaBN4cExVDN4xu2PNHikG/L3 Hr/ki75+ZQ9/kOy8gUnVJKavr7dcx8yym3ZZMfOswwyVf7deFIvsTNtDEEkVHcfkVLcN eEwg==
X-Gm-Message-State: AODbwcBvW5ZX7qq7lfRKbL5YMb4xeHYTybLwx2KXTCDqHeO/+kvs/ktd iWb6cSD9GJ0r24pXP/DfwtrOo8J5mg==
X-Received: by 10.13.232.10 with SMTP id r10mr9314490ywe.161.1496875289448; Wed, 07 Jun 2017 15:41:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com> <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <alpine.DEB.2.02.1706050827290.17963@uplift.swm.pp.se> <E2B77C58-B235-49D6-8130-0B41BE55899C@google.com> <CAAedzxrkbywKMmUaZ6-OCunXe1sw=q3+TNz278xZDmdsQm3xaw@mail.gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <CAKD1Yr3+pHFhCwoL4vbQLDQ3PNGpijci8c7eZM=Gb0oTy9C0XA@mail.gmail.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <EF9AC09C-5262-4DFB-AA4D-AE95EF81293C@gmail.com> <CB328974-E401-4B62-A408-1814183E0010@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com>
In-Reply-To: <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com>
From: Ca By <cb.list6@gmail.com>
Date: Wed, 07 Jun 2017 22:41:18 +0000
Message-ID: <CAD6AjGSvaAGydOjZ-LYA8=DR2pOjmUrYAGN0kVdC2aKb3jvx_A@mail.gmail.com>
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
To: Fred Baker <fredbaker.ietf@gmail.com>, james woodyatt <jhw@google.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c088658e6ae6d0551666fc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/82PftwUbMFp8nhOg_IlObzxEDC8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 07 Jun 2017 22:41:32 -0000

On Wed, Jun 7, 2017 at 1:43 PM james woodyatt <jhw@google.com> wrote:

> On Jun 7, 2017, at 13:21, james woodyatt <jhw@google.com> wrote:
>
>
> I see no dogs wagging. From my perspective, I see a wagging tail on a dog
> that doesn’t even know it has one.
>
>
> Furthermore, I should clarify that I’m taking no position whatsoever
> against what I view to be an effort to update IPv6 Address Assignment to
> End Sites [RFC 6177] to drop the following reaffirmation on page 3:
>
>       A key principle for address management is that end sites always be
>       able to obtain a reasonable amount of address space for their
>       actual and planned usage, and over time ranges specified in years
>       rather than just months.  In practice, that means at least one
>       /64, and in most cases significantly more.  One particular
>       situation that must be avoided is having an end site feel
>       compelled to use IPv6-to-IPv6 Network Address Translation or other
>       burdensome address conservation techniques because it could not
>       get sufficient address space.
>
>
> I no longer feel this must be avoided. It’s too late to stop that from
> happening. It now seems perfectly acceptable that end sites should feel
> compelling to use IPv6-to-IPv6 Network Address Translation or other
> burdensome address conservation techniques because it cannot get sufficient
> address space.
>

I am unfamiliar with thread () in the real world and don't yet feel
compelled to believe a widely deployed ietf standards track specifications
should bend due some niche design choices that may or may not achieve a
significant deployment.

Thread () makes design choices and they deal with them.  Same for ietf.

I believe i am agreeing with Fred


>
> --james woodyatt <jhw@google.com>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>