Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Joe Touch <touch@isi.edu> Thu, 08 November 2012 21:21 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C221F8689 for <v6ops@ietfa.amsl.com>; Thu, 8 Nov 2012 13:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPfreKpomCaj for <v6ops@ietfa.amsl.com>; Thu, 8 Nov 2012 13:21:14 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 706CF21F8685 for <v6ops@ietf.org>; Thu, 8 Nov 2012 13:21:14 -0800 (PST)
Received: from [192.168.1.115] (24-121-24-110.npg.sta.suddenlink.net [24.121.24.110]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA8LJn9B014327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 13:19:59 -0800 (PST)
Message-ID: <509C21F5.4030704@isi.edu>
Date: Thu, 08 Nov 2012 13:19:49 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Bob Hinden <bob.hinden@gmail.com>
References: <CAKD1Yr13cNspdWvTaXxHt4R_8UB-CKeA4nq8_XWrkbFGCgW7Gg@mail.gmail.com> <5090DECF.3050100@gmail.com> <CAKD1Yr1dUy-f78A2+kfA7NjpzD0WQRT8iwqGYAm5A=Erodpn-A@mail.gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <CAKD1Yr0mTTcVeq+Qf0fLv3UCBP_90QmStkK3Ha4tDdm3FxJjVA@mail.gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> <509A7922.9080000@gmail.com> <509A8993.4000803@isi.edu> <55E816CE-22B4-4C81-BC8C-61D932782192@employees.org> <0B60F4C0-0E86-4F7F-8B22-7CC0E471D11F@gmail.com>
In-Reply-To: <0B60F4C0-0E86-4F7F-8B22-7CC0E471D11F@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Fernando Gont <fgont@si6networks.com>, v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2012 21:21:15 -0000

Well, I see only the word "should" here. Given how vendors already 
ignore "musts", I doubt we can expect them to be held to "shoulds".

I agree with the intent, but am suggesting that any update on this issue 
might take the opportunity to clarify intent.

Joe

On 11/8/2012 1:05 PM, Bob Hinden wrote:
>
> On Nov 8, 2012, at 2:05 PM, Ole Trøan wrote:
>
>> Joe,
>>
>>> There's remains other problematic language in 2460, however:
>>>
>>>   Each extension header should occur at most once, except for the
>>>   Destination Options header which should occur at most twice (once
>>>   before a Routing header and once before the upper-layer header).
>>>
>>> So it still seems open to have more than one HBH header, which certainly complicates things even though they'd be clearly marked.
>>
>> I don't see how you can read that to imply you can have more than one Hop-by-Hop extension header.
>> my reading (and what I think the _intention_ of the text was) is that there can only be one Hop-By-Hop extension header, and
>> that the HBH header must be the first extension header in the chain. this way routers only need to check the Next Header field
>> for the value of 0.
>
> +1
>
> Bob
>