Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 25 February 2017 10:02 UTC

Return-Path: <alexandre.petrescu@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 93144129CAC for <ipv6@ietfa.amsl.com>; Sat, 25 Feb 2017 02:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.332
X-Spam-Level:
X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, 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 1qMphfyXV1UQ for <ipv6@ietfa.amsl.com>; Sat, 25 Feb 2017 02:02:47 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55065129CA6 for <ipv6@ietf.org>; Sat, 25 Feb 2017 02:02:47 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1PA2j16031624 for <ipv6@ietf.org>; Sat, 25 Feb 2017 11:02:45 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E64E0207F68 for <ipv6@ietf.org>; Sat, 25 Feb 2017 11:02:44 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC6B5200E05 for <ipv6@ietf.org>; Sat, 25 Feb 2017 11:02:44 +0100 (CET)
Received: from [132.166.84.73] ([132.166.84.73]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1PA2iFU005895 for <ipv6@ietf.org>; Sat, 25 Feb 2017 11:02:44 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: ipv6@ietf.org
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAN-Dau0s04c=RV0Y8AGaxBPFui41TWPTB+5o0K2Lj-iah0An1w@mail.gmail.com> <CAL9jLaYirty22iGiEjEaYq3_KA1FZhxBTOBWuFOXQ9C-WPd5xQ@mail.gmail.com> <CAN-Dau0n6oFm538XdJOcuO1yg92BCDD3mBu5YfBVm_+g-gtcKA@mail.gmail.com> <CAL9jLaYO=uYgVfSZ0SoSe0SujJ1xgwEKE8WLzo_keJHywgXTtg@mail.gmail.com> <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>
Date: Sat, 25 Feb 2017 11:02:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lXQIAW_FDXMejfDuysH75E0w15g>
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: Sat, 25 Feb 2017 10:02:49 -0000


Le 24/02/2017 à 21:02, David Farmer a écrit :
>
>
> On Fri, Feb 24, 2017 at 1:55 PM, Christopher Morrow
> <christopher.morrow@gmail.com <mailto:christopher.morrow@gmail.com>> wrote:
>
>
>
>     On Fri, Feb 24, 2017 at 2:51 PM, David Farmer <farmer@umn.edu
>     <mailto:farmer@umn.edu>> wrote:
>
>
>
>         On Fri, Feb 24, 2017 at 1:36 PM, Christopher Morrow
>         <christopher.morrow@gmail.com
>         <mailto:christopher.morrow@gmail.com>> wrote:
>
>             sorry, a clarification request below.
>
>             On Fri, Feb 24, 2017 at 1:42 PM, David Farmer
>             <farmer@umn.edu <mailto:farmer@umn.edu>> wrote:
>
>
>
>                 On Fri, Feb 24, 2017 at 12:11 PM, james woodyatt
>                 <jhw@google.com <mailto:jhw@google.com>> wrote:
>
>                     On Feb 24, 2017, at 03:11, Nick Hilliard
>                     <nick@foobar.org <mailto:nick@foobar.org>> wrote:
>>
>>                     Let me be more specific then: are you proposing
>>                     that vendors write code
>>                     to allow or disallow interface subnets which
>>                     aren't /64 (or /127)? This
>>                     is a binary choice; a vendor needs to choose one
>>                     way or another.
>
>                     I don’t know how I can be more clear about this: I
>                     insist that general purpose host operating system
>                     developers should be expressly permitted to write
>                     code that declines to accept subnet prefixes of any
>                     length other than /64 on the grounds that these are
>                     not used in general IPv6 networking and the
>                     successor to RFC 4291 continues to say so.
>
>                     I know there are operating systems with billions of
>                     units in the field today that do exactly this
>                     because RFC 4291 and its predecessors have for years
>                     given them clear license to do so, and I don’t want
>                     to see the publication of I-D.ietf-6man-rfc4291bis
>                     as RFC come to remove this license as a side effect
>                     of promoting IPv6 to full Standard category.
>
>                     You want to remove that license? I suppose we can
>                     continue discussing that, but I think you should try
>                     to do it in a separate draft once IPv6 is officially
>                     promoted.
>
>                     --james woodyatt <jhw@google.com
>                     <mailto:jhw@google.com>>
>
>
>                 I would not want to make code that does /64 only out of
>                 compliance with the spec, especially for SLAAC.  I would
>                 like to discourage that stance, maybe for DHCP, but for
>                 sure for manual configuration if that mode is provided.
>                 But, I don't see /64 only as a invalid stance for an
>                 host OS to take.  But neither do I want the spec to
>                 disallow non-/64 for DHCP, manual configuration, or
>                 potential new modes of configuration if we ever get
>                 there.  I think SLAAC should to remain /64 only. I think
>                 DHCP and manual configuration should be encourage to
>                 support non-/64 options, but even they should allow /64
>                 only.
>
>
>             please restate your last sentence... I think you missed a
>             word or three?
>
>
>         It's still ok for a host OSes to do /64 only with DHCP and
>         manual config, not preferred.  I'd prefer host OSes support
>         non-/64 as well for DHCP and manual config, but not mandatory.
>         Only /64 should be REQUIRED of anyone, host, router, or what
>         ever.  Non-/64 should be OPTIONAL for everyone.
>
>         Is that clearer?
>
>
>     clearer, but not what I was expecting...
>
>     OPTIONAL means 'will not happen without customer loud voices'
>     (generally).
>     I'm worried that OPTIONAL is going to cause problems :(
>
>
> I was trying to be conservative in the change to push through the
> process. I'd be open to RECOMMENDED, but I don't see REQUIRED as an
> option, it would break too much

Depending how it reads...

I would agree if I read "/64 was RECOMMENDED in the past".

I would not agree if I read "/64 is NOT RECOMMENDED".

I would not agree if I read "/64 is RECOMMENDED".

Alex

>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> <mailto:Email%3Afarmer@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>