Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 24 November 2019 19:16 UTC

Return-Path: <jmh@joelhalpern.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 E55B8120041 for <ipv6@ietfa.amsl.com>; Sun, 24 Nov 2019 11:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 OCgetenVCTTI for <ipv6@ietfa.amsl.com>; Sun, 24 Nov 2019 11:16:43 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 9AE0A120018 for <6man@ietf.org>; Sun, 24 Nov 2019 11:16:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47Lfzb2jpvz1hvxy; Sun, 24 Nov 2019 11:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1574623003; bh=bGDQpx+MRS5rg28wl82f3yrXI2SLEvi8i2jAF+eJoz4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=L1MA8hpnHwsO9l/0Xw7pjdrVKjRIRfb7pqfSSHOx192M0or9hXiK4QNNYDlbA2N44 wi2rqsSm3alpgwDbX05ur+ZmBlp+1iXDxFD4wCtG7a4NgYZtPQTobUo3n/WQMQWWSS WaubrZNnovh96PURcf8J3SvBP102o2IhSNvvKwIo=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47LfzZ1pNTz1hvxv; Sun, 24 Nov 2019 11:16:42 -0800 (PST)
Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Sander Steffann <sander@steffann.nl>
Cc: 6man <6man@ietf.org>
References: <157422734071.5406.14331301768750185617.idtracker@ietfa.amsl.com> <851F7007-3DD5-42F3-8884-8842DA07EE53@cisco.com> <1cfd682f-d6bc-a697-38a7-933aa0485b8a@si6networks.com> <D4436EF5-2B97-44A4-915D-EF7611590B51@steffann.nl> <51AAA37A-847E-48B9-8965-7449898B8F18@employees.org> <C03A0BD7-0662-4C5C-B4D9-6FE776A53AD6@steffann.nl> <1a72cf0b-b6c5-8f64-0d23-b8fea89e252a@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <e3b6c54c-5795-0fad-b113-0cebf1fb078a@joelhalpern.com>
Date: Sun, 24 Nov 2019 14:16:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <1a72cf0b-b6c5-8f64-0d23-b8fea89e252a@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/t_nU5wdXlkRwEqKr0jDHl34HqbI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 24 Nov 2019 19:16:46 -0000

There is no reason I know of for the IETF to publish an RFC on the IETF 
stream that describes interesting ways that deployers have violated 
RFCs.  If the deployers want an RFC, the Independent Stream can be used 
to publish such things.  Particularly if the document actually describes 
meaningful values for there violation.

Yours,
Joel

On 11/23/2019 6:59 PM, Brian E Carpenter wrote:
> Hi Sander,
> 
>> - I object to not updating RFC8200 in any RFC that contradicts its content. If EH insertion should be accepted by this WG despite the objections then implementers reading RFC8200 need to know that a conscious exception has been made.
> 
> So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for the Internet. I wouldn't object to adding an explicit statement of this to the draft, because that's also a true fact. But I would be very sad if the IETF is now against publishing factual information about actual practice that we are not willing to standardise, in line with https://tools.ietf.org/html/rfc2026#section-4.2.2 paragraph 2.
> 
> If we had standardised mechanisms for establishing limited domains, we could do better than that, but we aren't there yet.
> 
> Regards
>     Brian Carpenter
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>