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

David Farmer <farmer@umn.edu> Fri, 18 November 2016 00:42 UTC

Return-Path: <farmer@umn.edu>
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 068CD128E18 for <ipv6@ietfa.amsl.com>; Thu, 17 Nov 2016 16:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level:
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 qMfPMHe-5ten for <ipv6@ietfa.amsl.com>; Thu, 17 Nov 2016 16:42:31 -0800 (PST)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6278312961C for <ipv6@ietf.org>; Thu, 17 Nov 2016 16:42:31 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 75261A06 for <ipv6@ietf.org>; Fri, 18 Nov 2016 00:42:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIATFdtMeupT for <ipv6@ietf.org>; Thu, 17 Nov 2016 18:42:30 -0600 (CST)
Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 457F9C1F for <ipv6@ietf.org>; Thu, 17 Nov 2016 18:42:30 -0600 (CST)
Received: by mail-qk0-f199.google.com with SMTP id y205so209054267qkb.4 for <ipv6@ietf.org>; Thu, 17 Nov 2016 16:42:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AFRCAHRDRSbO7YaaM4EbEXjEsUPJE6NcdpQA4fSkadQ=; b=OggDC1qxotV8UOm5zRJoX4ug19DbMYPTwxQogDpznACAchcfZ5RIrMO89S4Hpg1ATr 2V1tfxKwBMx69jpTxc7lTPtDnDEArgFX1qw57sN4bUPJaRbemE47nOxyB4hboapEKAC1 8zf75y1PqLwLX/7tNFzyM6GNzGrqA0b7qw47g4m9WvTcEBB8so/xMrJ+ylLzSkTCyfGI jTBmPmVGRoHz+qgGyGFKiEt0XKXCZoyYrIMXceQg6NlBemxtVBiALid8d/l9vwR0K4nM QeW0jtzrRH8HK55WCNZK2W+5N7io7yL/LZFdxf2WTaj1IG2z/2nGlm5TrQ11pjUzIMxr qzyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AFRCAHRDRSbO7YaaM4EbEXjEsUPJE6NcdpQA4fSkadQ=; b=L4PtZw75vkV+87PcM5WWAZc2rFfaRD3bv0WV+F9BgeCB96dCSZzwDJXdhBUdWALVsM Qzfxc7bImklSLfPFQWvRCPvIgBHDBoqAkcZTKZJSaNeR0t7RyP1CAz8UEenBxpbBkTIA Xt2gs98mP3AktUWFUKlEHn5SseL9/T6UiCYOjdSieNEXW1ZGXVzilN6cuYuCaBNK2m4L LqN4D+cvzWjnFPgkPtiPg803Ct0Io6LZcaCTQYMRVtUMIkP/ePrxdxulgCYNvPIkOwU6 u6rE791ob2dGOFpagwYpECK88mK4vXm9Qe1eGttenX03N6DiW9WXNHJ4E6wVCuxjxre1 X9cA==
X-Gm-Message-State: AKaTC03pwpdxviAljcrSAuwoyavOcEvaFL8JLTvlKmjQkoN5fLDCFf60ERVeKSYB84XdzMD2WZZIy07EU6EBOQ98jDqXKIGfEx1FStjr/BLpvbocpgTxceieC4Lmb0UgoHcVO3soxad5n3jIZI4=
X-Received: by 10.55.0.65 with SMTP id 62mr7020766qka.106.1479429749770; Thu, 17 Nov 2016 16:42:29 -0800 (PST)
X-Received: by 10.55.0.65 with SMTP id 62mr7020751qka.106.1479429749540; Thu, 17 Nov 2016 16:42:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.198 with HTTP; Thu, 17 Nov 2016 16:42:28 -0800 (PST)
In-Reply-To: <419dc1e4-ec89-36d9-1097-80055dff5bd2@gmail.com>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org> <CAJE_bqczRSZYWC3tDLXvxRMzqnV9nDjYjUddyRHtwfpGEXvm5w@mail.gmail.com> <189a5939-71c8-f686-b34c-cbf410d55374@gmail.com> <CAO42Z2z_Zm82DZf9xusCUXPe=8pChZX7KR+9aEK38htfGge9Hg@mail.gmail.com> <419dc1e4-ec89-36d9-1097-80055dff5bd2@gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Thu, 17 Nov 2016 18:42:28 -0600
Message-ID: <CAN-Dau31w6g8rGnZGaqWLXVjqer+5DzuQKfqzrT8huOnLyQoaw@mail.gmail.com>
Subject: Re: Next steps on advancing core IPv6 specifications to full Internet standard
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="001a11404460b11c580541889414"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OfY-b9hdixz4Rw2JE6NbzPUb40Y>
Cc: 6man-chairs@ietf.org, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, 神明達哉 <jinmei@wide.ad.jp>
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 00:42:33 -0000

On Thu, Nov 17, 2016 at 4:43 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 18/11/2016 10:45, Mark Smith wrote:
> ...
> > I'd really like to see it explained how those EH sections if RFC2460 are
> > ambiguous before I'd be willing to accept that claim.
>
> Mark, ambiguity is in the mind of the reader, not the writer. So when
> I see people who cite RFC2460 and who believe that it allows header
> insertion, and other people (including myself) who believe that it forbids
> header insertion, that's an operational proof of ambiguity.
>

I wanted to stay out of this one, but to be honest;

I read the current language in 2460bis-08 as "intermediate nodes SHOULD NOT
insert EH, its RECOMMENDED that you encapsulate."

Where as the original 2460 text, does not explicitly address the issue, but
I don't see how it can be interrupted as allowing an intermediate node to
insert an EH.

What I heard asked for is that 2460bis explicitly address the issue, that
is to make it abundantly obvious that "intermediate nodes MUST NOT insert
EH".

While I agree with this personally, I also agree there doesn't seem to be
consensus for that.

I can not agree with the proposed text, and at this point I would prefer
the original 2460 text, if there isn't a consensus for making it abundantly
obvious that "intermediate nodes MUST NOT insert EH".

Not sure that helps, but I tried.

-- 
===============================================
David Farmer               Email:farmer@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
===============================================