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

Fernando Gont <fgont@si6networks.com> Thu, 23 February 2017 07:35 UTC

Return-Path: <fgont@si6networks.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 D537C12963D; Wed, 22 Feb 2017 23:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 QGa0lWSwloW1; Wed, 22 Feb 2017 23:35:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10FD129639; Wed, 22 Feb 2017 23:35:12 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 82ECC828A5; Thu, 23 Feb 2017 08:35:07 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <lorenzo@google.com>
References: <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <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> <m2a89dveop.wl-randy@psg.com> <CAKD1Yr1igJiL_2BVi=RL_Wkd6V0O6WaPJ5fMS+ggVkTRAOdPXw@mail.gmail.com> <3f6b3814-34ee-e8e4-3746-85b3e7e208d8@si6networks.com> <CAKD1Yr0LHCT9_3QzaDY=XKWwSsA5CtE-4EqaQsp_Fp_3-Y56GA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <30dda6a9-2683-8157-1b75-9aa154b8deb7@si6networks.com>
Date: Thu, 23 Feb 2017 04:33:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr0LHCT9_3QzaDY=XKWwSsA5CtE-4EqaQsp_Fp_3-Y56GA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yLahMcKfsLb8IovsEV88g-b72Iw>
Cc: Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@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: Thu, 23 Feb 2017 07:35:15 -0000

On 02/23/2017 03:24 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 1:25 PM, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
> 
>     > (I do also happen to think that it would be better if we waited a decade
>     > before changing this, because we're only 5 or so years into large-scale
>     > deployment that will hopefully last at least 3 or 4 decades. However, I
>     > don't expect many people to agree with me on that, so I'm not trying to
>     > make that argument here.)
> 
>     Isn't that actually an argument for waiting before moving rfc4291bis to
>     full standard?
> 
>     If you'd wait to change it, why would you want to cast this into stone
>     now? So that, later you can argue that "it's a full standard document...
>     so we shouldn't change it"?
> 
> 
> I don't see why that argument would carry any weight. Full standards can
> be changed and updated, too.
> 
> What I most care about is that if we make fundamental changes like this,
> then it's not done as part of a reclassification, and the working group
> has its say.
> 
> Whether the document says "full standard" or "draft standard" is not as
> important as whether it says the right thing.

Exactly. And if a document does not reflect operational reality, it has
a big problem.

My understanding is that Randy et al are trying to get rfc4291bis to
reflect operational reality, but you want to progress the document with
no changes, essentially meaning that you want to publish a document as
full standard which doesn't agree with how the protocol is being deployed.

If, even at the time of publication our documents already do not reflect
reality, we are not going to be taken seriously.

If you're argument is that we cannot do what is right because moving
rfc4291 to full standard doesn't allow it, then you're implicitly asking
not to move rfc4291bis to full standard (or are just aasking us to do
the wrong thing).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492