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

Susan Hares <shares@ndzh.com> Sun, 27 September 2020 01:04 UTC

Return-Path: <shares@ndzh.com>
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 3FAFF3A0E1E; Sat, 26 Sep 2020 18:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.223
X-Spam-Level: *
X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PCLBvMLSZR_J; Sat, 26 Sep 2020 18:04:36 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 33ABC3A0E1B; Sat, 26 Sep 2020 18:04:35 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.164.118;
From: "Susan Hares" <shares@ndzh.com>
To: "'Christoph Loibl'" <c@tix.at>, "'John Scudder'" <jgs@juniper.net>
Cc: "'idr@ietf. org'" <idr@ietf.org>, <draft-ietf-idr-rfc5575bis@ietf.org>
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <2524BF03-8CC3-49A7-8925-0E6B085A461A@juniper.net> <27FE8C86-09DD-41E9-8B69-4CF4550E2019@tix.at>
In-Reply-To: <27FE8C86-09DD-41E9-8B69-4CF4550E2019@tix.at>
Date: Sat, 26 Sep 2020 21:04:25 -0400
Message-ID: <009401d6946a$25f49b00$71ddd100$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01D69448.9EE40C70"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQJFO/98nG4CXpcqgpkjUdeb0RRdigIvkkgpAi17d2eoe3NTUA==
X-Antivirus: AVG (VPS 200926-6, 09/26/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/m6Y-xHvfgSmNgTHJ9W6NQvHC800>
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: Sun, 27 Sep 2020 01:04:38 -0000

Chrisoph and John: 

 

I’m fine with the word change as well.   I thought it was clear – but anything that helps make this very clear is fine with me. 

 

Sue 

 

From: Christoph Loibl [mailto:c@tix.at] 
Sent: Saturday, September 26, 2020 4:49 AM
To: John Scudder
Cc: idr@ietf. org; draft-ietf-idr-rfc5575bis@ietf.org; Hares Susan
Subject: Re: [BULK] [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

 

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