Re: Next steps on advancing core IPv6 specifications to full Internet standard

神明達哉 <jinmei@wide.ad.jp> Fri, 18 November 2016 19:14 UTC

Return-Path: <jinmei.tatuya@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 92A9712948A; Fri, 18 Nov 2016 11:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 bkoDewbfRi8O; Fri, 18 Nov 2016 11:14:09 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 760B3129493; Fri, 18 Nov 2016 11:14:09 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n204so276120186qke.2; Fri, 18 Nov 2016 11:14:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=la9TlbgtOtPftjZeiOpza/7vQnEC+nL1e20+hmKklQI=; b=cxn41YuNjXY4CDyNc45G7dZEBvTAqWS+6+N8OX3llFSwE+RtO7FnX/1Rod+6hghCyg lDX+bacwdd0J+UN4IgW10yMy2BKVeIABNQ9M7Z/u+dkdow4M8fCHsc23L762gOT2vERz 8+zddAjj3/gLM0I41pXtdyGHhlFguEHFfJjEQao7X8HeX7YsolV9V/4c+FZGOPS70Pvd hHIVeKI/c+1Ldez00tJZPXwDKNRwuXWY/6H8ZFurZkGD6W3H/Q11jW/KDSUDhDlkL4jm +VSfUH609jk4lBTWh9JTxlRI0Evy08ggbifMTRTLLiCmFDG0meZsl6CPOwBLZRs6lXEn OYdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=la9TlbgtOtPftjZeiOpza/7vQnEC+nL1e20+hmKklQI=; b=BdEr5Nyo1T01H3C65ryEgtNYnl8/gjpOdf4Eee+rj8VqzfNAeJGsAw0cKMpAkbSGlC EDFsfDUwWBHMvJ0eMmcNJO85ctHnG8spIlO/eSSTbK3SwZd9OI4YBBMbtwGwhl+04e5t Hx6xzR5dxXjVQ3VoeWw7PQIY9CSLzuiXRIIdttQtp+f6ms6FOcW4B3wQmmMfSSUnZyRz 4JP9lyU34X60Z1ehSdYjqKwhTKG+RfhFsgWlv6MZ0Y+lXvmQVMJX44zuiKpCDaAom+Qo 20UwgQI22yqsnL5ZuaDBJH0sHqdUHq/dTISKi5e+hJ5ZR3fC+FH0yfetGJTusnkaTroK GBKQ==
X-Gm-Message-State: AKaTC01C9BQ7tvm3zSAqnvhQyr1gLzWzscM7HTZiXBU/llwYJEJGiQRDDIQpr9oa2iEvrHBTH8+ffkAobOOtyw==
X-Received: by 10.55.51.201 with SMTP id z192mr1528556qkz.311.1479496448569; Fri, 18 Nov 2016 11:14:08 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.53.155 with HTTP; Fri, 18 Nov 2016 11:14:07 -0800 (PST)
In-Reply-To: <85517D4C-488E-4A05-9E2C-5D4604DF69B8@gmail.com>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org> <CAJE_bqczRSZYWC3tDLXvxRMzqnV9nDjYjUddyRHtwfpGEXvm5w@mail.gmail.com> <85517D4C-488E-4A05-9E2C-5D4604DF69B8@gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 18 Nov 2016 11:14:07 -0800
X-Google-Sender-Auth: 0MDpaKyaCkBfc_XXD6W8N39k3U4
Message-ID: <CAJE_bqf8=XwoOBswpTrrEWjB2o=n8f8x6cVEMdkWA4wdrMA=4Q@mail.gmail.com>
Subject: Re: Next steps on advancing core IPv6 specifications to full Internet standard
To: Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OxlnZTR3PT7tkNE0Ly9Etx5-naI>
Cc: IPv6 List <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, 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, 18 Nov 2016 19:14:11 -0000

At Thu, 17 Nov 2016 22:55:04 +0900,
Bob Hinden <bob.hinden@gmail.com> wrote:

> As Brian Carpenter noted, “ambiguity” is not called out in RFC 2026
> or RFC 6410.  The issue has existed since RFC2460 (and RFC1883
> before that).  We think the real issue is if this causes an
> interoperability problem.  There doesn’t seem to be an evidence that
> there is an interoperability problem.  We think the new text will
> help by describing the problem.

I don't want to waste everyone's time by just repeating what I said
before (which would possibly be another round of the same discussion),
but this logic ("we don't have to or shouldn't clarify the ambiguity
since there is no evidence that the lack of clarification caused an
interoperability problem") is one major thing I've not
understood/bought throughout this discussion.  With that logic we
could never introduce a MUST NOT when designing a new protocol, since
obviously there's no evidence of an interoperability problem in such
cases.  Also, in the case of this header insertion issue, I suspect
the more likely situation is that the original intent (of not allowing
an intermediate node to insert EHs) was actually pretty clear for most
of us, so there were simply very few attempts to violate it (and when
it was violated it, it was probably quite limited or they were very
careful to control the setup to avoid interoperability problems).  If
that's the case, the question to be asked is not whether there is an
evidence of an interoperability problem but how likely it can cause
such a problem if we allow casual violation of the original intent.
I interpret the consensus of describing the problems as most people
agreed (perhaps reluctantly for some of them) it's quite possible.
And, in that case, I believe we should also clarify the ambiguity that
can make the problems happen.

Anyway, I don't intend to make this thread unnecessarily longer just
for another round of the same discussion, so I'll shut up here.  I'll
basically just see if there are other people who were not in the f2f
session and are willing to revisit the consensus at that time.

--
JINMEI, Tatuya