Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Jeff Tantsura <jefftant.ietf@gmail.com> Thu, 30 March 2017 13:12 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F071294C4; Thu, 30 Mar 2017 06:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 h9oxSGcyYfnZ; Thu, 30 Mar 2017 06:12:01 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 7D1B41294E5; Thu, 30 Mar 2017 06:12:00 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id y18so1843938itc.1; Thu, 30 Mar 2017 06:12:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=9WQ7aB6vOJr1y7R0P5/9V9w9T05gr0aI9C9EMyRo9eg=; b=i8Rg94o9+SiFlNew/sVHkegPsLfsVdLovEHVgK9YMhdYFOUupl/si3AnFGu39jBZKw ds4Ysv50MqCC+UmdwxKFlrKcOKPk8S2P2SUyKRcgyOKEAwXuH7qosbqeBIMUswpsG+F2 lohw59sD+cPCTz8IO6W86VtygilJAYZXsn1kWUO9FvdRj5qVpesgWzPFv6wc9mpyopcn 376t04XJBbI3919TznT4A/iOaOCAX4bnbACEXnaIMP6P4zYj/llYjT8edRxKxYXKecMX 2yw7ke1ST552YUjvLKd60PPmKpqi1/P9iFFYHh0SU0LvoHxDK5VbPEnkvZvMkFf7U/gQ /tsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=9WQ7aB6vOJr1y7R0P5/9V9w9T05gr0aI9C9EMyRo9eg=; b=Obzl268B24W21d6hQ2jKmH7V4Gu+yjSdS1Xo59lf1sBhiApwbboTtlMWXjpb06qaM4 wZXD/bGdarsunG/gWoeN4SyI1PT3gCwN+p+P/F9TgrdBjRkin3a5iIxaHhzTYLRN75Gn mkZtSUiqsSh3PttrKYJ3Wu/OdmsiS08PVv9HWbx+ZgrTcbHfWQvaDCJ3AEqrOvRlVzR8 1ErCluQQkftv5Te+qvbphLZiIi7/eOXhoEtkOrq4Eyg4mvpLTEFbo8XkLVgJuariKgM4 3WgJUY1VrqJYIx/l9lbG9rvqrcREdNwJxIz0zOJgO2xLoQxXkt16V/ZbCDCVbD2eUKM2 k9wg==
X-Gm-Message-State: AFeK/H2eHo2nQlEfYYWrq7jVtMSyq+8kU13Owei/voOsUrGOVTAZyopyjHh5ZzJAQvS8LA==
X-Received: by 10.36.43.78 with SMTP id h75mr311776ita.25.1490879519903; Thu, 30 Mar 2017 06:11:59 -0700 (PDT)
Received: from [31.133.143.171] (t2001067c037001284d2da5a9acf593c2.v6.meeting.ietf.org. [2001:67c:370:128:4d2d:a5a9:acf5:93c2]) by smtp.gmail.com with ESMTPSA id v185sm1328437itf.11.2017.03.30.06.11.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:11:58 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Thu, 30 Mar 2017 08:11:57 -0500
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Leddy, John" <John_Leddy@comcast.com>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>
CC: "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, 6man <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Message-ID: <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com>
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com>
In-Reply-To: <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/t9XFBPgLyECyqvZjW_6X2jKxkig>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 13:12:08 -0000

Brian,

if I understand you correctly: 

If properly worded (improved) draft-voyer explicitly states – the intention is to change the 2460(bis) behavior and to allow header insertion within a controlled domain, and given there’s a valid justification of why encap wouldn’t’ meet the need, you wouldn’t oppose? 

Thanks! 

Cheers,
Jeff

On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <ietf-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:

    On 30/03/2017 15:59, Leddy, John wrote:
    
    ...
    > If this insert/delete of an SRH is prematurely prohibited;  What is a recommended solution to the Real World problem above.  Not use case, we are implementing.
    > 
    > Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking,
    
    I've tried to say this before but I'm not sure people are getting it: 
    
    RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others. 
    
    There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that.
    
    There doesn't need to be a tussle here. 
    
       Brian Carpenter