Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Nick Hilliard <nick@foobar.org> Mon, 22 February 2021 15:27 UTC

Return-Path: <nick@foobar.org>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCA73A07F7; Mon, 22 Feb 2021 07:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 MVubopojfHC8; Mon, 22 Feb 2021 07:27:08 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2083A0D08; Mon, 22 Feb 2021 07:23:14 -0800 (PST)
X-Envelope-To: tsv-art@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 11MFN6f8089441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2021 15:23:06 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
To: Tom Herbert <tom@herbertland.com>
Cc: Fernando Gont <fgont@si6networks.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org, last-call@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, IPv6 Operations <v6ops@ietf.org>
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com> <0e377231-c319-2157-30a0-759e2f96a692@gmail.com> <5f464f17-85ed-f105-35f9-02f35d04aed2@si6networks.com> <CALx6S364zGbq_HZNNVEaJHnHccuk4Zau2DXhmaVYbwnYQc-5bw@mail.gmail.com> <1847e8e3-543f-5deb-dd14-f7c7fa3677db@si6networks.com> <CALx6S34TPppMRJrOvyJ05LLeRvv+S51pQHJnzZDKk-qOdsF0AA@mail.gmail.com> <e41f3484-f816-e185-2d99-94323c8da732@si6networks.com> <CALx6S34qSxGijVcs229bAL5gMhMvMNYUXm3yEmrg6wxUiUAiaA@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <7758bf30-b39e-8fb0-cab8-40d60aa14d0b@foobar.org>
Date: Mon, 22 Feb 2021 15:23:04 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.46
MIME-Version: 1.0
In-Reply-To: <CALx6S34qSxGijVcs229bAL5gMhMvMNYUXm3yEmrg6wxUiUAiaA@mail.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/tsv-art/lC1jIcAwkvxZaAiv1daxfjRqGJQ>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Feb 2021 15:27:11 -0000

Tom,

We're talking at cross-purposes here. This is a descriptive 
Informational draft.  Its aim is to describe a specific problem set 
relating to an ipv6 protocol component.

Tom Herbert wrote on 22/02/2021 14:55:
> Yes, different routers do different things, but can you quantify what
> the most commonly deployed routers do? If we can do that then we could
> establish a better requirement for host stacks more than just "don't
> send IPv6 header chains that are too long".

... which proposes to turn the draft into a prescriptive draft, i.e. to 
advise on what protocol implementers should do.

We totally get the value proposition of what you're suggesting, but it 
doesn't belong in this draft.  Establishing workable limits is both 
difficult and subjective, which is why our proposal is that it should be 
in a future draft which would probably end up being a BCP.

Nick