IETF Logo Mail Archive

Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Christoph Loibl <c@tix.at> Sat, 26 September 2020 08:48 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1873A1191; Sat, 26 Sep 2020 01:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 NGbxHBFoENJZ; Sat, 26 Sep 2020 01:48:53 -0700 (PDT)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (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 850CF3A1190; Sat, 26 Sep 2020 01:48:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8edDEf98OsrOkHRmr0S9QU+ivP+6YN+CJKZyKDh2eUc=; b=A/bVzwXEJJtfkBOtiGcRFetvUe TdcCcj38wROnRFYcz/RglQXWIdXTwvwUmowxKkUFWwbBdfa0f8+J9onKk43KB/1Yq3VSJNY6N23V1 LuyApk+3kw3NoGTakIMhgqUFe4A6iCcLMvHla2rV0is+AUVP2B8wyuR4ifevjq9D1NyhYU0NM4x/v Btlqk6DHZxKXkjSvKnJtNRuLwZcRkIUaS5SoxP9FOqCr8U3+AV1xSViIO0k3tLwNfsyvcwJBbCyFi 2qg51vEdVhSsHlA8aMF371efE4ZDCt/8b8b7wIRv2PU9bWPGGPsWljayRToUkG2ipv8lAJoDRm8NY mx1k9l+A==;
Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kM5st-0006xS-7d; Sat, 26 Sep 2020 10:48:47 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <27FE8C86-09DD-41E9-8B69-4CF4550E2019@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_59F050CA-CCB9-4F72-A59E-E302D2709039"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Sat, 26 Sep 2020 10:48:46 +0200
In-Reply-To: <2524BF03-8CC3-49A7-8925-0E6B085A461A@juniper.net>
Cc: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, Hares Susan <shares@ndzh.com>
To: John Scudder <jgs@juniper.net>
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <2524BF03-8CC3-49A7-8925-0E6B085A461A@juniper.net>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Sat, 26 Sep 2020 10:48:47 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/n8gQlK0z9BWx3J8wLgk86WneZ4g>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2020 08:48:57 -0000

Hi John,

I agree that changing the name would do no harm.

Cheers

Christoph 

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 25.09.2020, at 21:14, John Scudder <jgs@juniper.net> wrote:
> 
> Hi All,
> 
> Jie brought up another point in a unicast email. He points out that 
> 
>> The description about component type 12 (Fragment) has been updated, the meaning of the Bitmask values is added. For Bit-6 (IsF), the new description is:
>>  
>>    IsF -  Is a fragment - match if [RFC0791] IP Header Fragment Offset is not 0.
>>  
>> This description is IMO a little bit confusing, as it simply says “is a fragment”, but the matching rule does not include the case of the first fragment (MF=1, offset=0),. Perhaps it could either update the matching rules to also include the first fragment case, or it may update the description as “fragmented and not the first segment”.
> 
> Let’s also discuss this before we take the document off of hold and continue its processing. Speaking for myself, I don’t find the quoted text confusing since the rule specifically says “fragment offset is not 0”, but on the other hand it would do no harm to change the description to the even-more-correct “Is a fragment other than the first” (I didn’t use “segment” as Jie does, since that’s potentially a new source of confusion; “segment” is a TCP term, not an IPv4 term, and it’s a *different* IPv6 term). 
> 
> Thanks,
> 
> —John

v2.23.0 | Report a Bug | By Email