Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-flow-spec-v6-19: (with COMMENT)

Christoph Loibl <c@tix.at> Mon, 09 November 2020 09:45 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 7C4163A0DAA; Mon, 9 Nov 2020 01:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 u9coOGkBNA9e; Mon, 9 Nov 2020 01:45:37 -0800 (PST)
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 192313A0DC8; Mon, 9 Nov 2020 01:45:35 -0800 (PST)
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=LpGbGgsPj6yXbjhR1QxYhi3lG5PnniGcgSXYwA8jxAo=; b=pJW+iE8jtx23Tg+iEWsZzimSVX XvlUNZV7zbw6lpNK5DJv8j7v+U6SW4roPuhU0ldGgI4gHfUQVMoSSMlPe3+UFlOqMxikHXuxzydie 9aBY8BB6rhaaljlFK1cFR1HtOI8VTtiglniA3wOxCgbrFDZdrSbAzmK7R0aqKJvv5Bd4d7g9JuJdE zxf2+NJuwRa5ckEnrXfKDZv+zUbIqW9ojc1pU3/tHaNtXBYnx8KM7SNwqT9Wnit++PZaQ8I/6NKWg flfx6HkDQNiDWEaWoJd4Eo9I8vy0GiZcE8S0+y0sHV9st4FyvP2wibYVci4E1Iqehb3kxpqj9PNa0 JwX+xugQ==;
Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.64.148]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kc3jv-0005ZZ-B6; Mon, 09 Nov 2020 10:45:32 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <788DE107-2AFD-419C-B579-50BF8D98EC37@tix.at>
Content-Type: multipart/mixed; boundary="Apple-Mail=_3CA5025C-52C9-4F7B-A813-5E7224CBC38D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 09 Nov 2020 10:45:29 +0100
In-Reply-To: <160448713212.21180.11299486836315882515@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-flow-spec-v6@ietf.org, idr@ietf.org
To: Robert Wilton <rwilton@cisco.com>
References: <160448713212.21180.11299486836315882515@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Mon, 09 Nov 2020 10:45:31 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/c4NJRmXdqcBTmnaBRy3GTRbdcjc>
Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-flow-spec-v6-19: (with COMMENT)
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: Mon, 09 Nov 2020 09:45:42 -0000

Hi Robert,

> On 04.11.2020, at 11:52, Robert Wilton via Datatracker <noreply@ietf.org> wrote:
> Thank you for this document. Even without the specific domain knowledge I found this document easy to read and understand.

Thank you for your review. We considered your comments and edited the document (see my answers inline below). The updated document will be published soon (datatracker is closed, so we cannot update too often) - see the attached document.

Cheers Christoph
 

> 
> A couple of minor comments that you may wish to consider:
> 
> ```
> 3.  IPv6 Flow Specification components
> 
>    Types 4, 5, 6, 9, 10 and 11, as defined in [I-D.ietf-idr-rfc5575bis],
>    also apply to IPv6.
> ```
> 
> Also giving the descriptive names for these types might aid the reader here.
> 

Christoph: Added the names of the types.


> ```
> 3.3.  Type 3 - Upper-Layer Protocol
> 
>    This component uses the Numeric Operator (numeric_op) described in
>    [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 3 component values
>    SHOULD be encoded as single octet (numeric_op len=00).
> ```
> 
> The "(numeric_op len=00)" threw me off at first, until I referenced back to section 4.2.1.1. Possibly, this might be more clear as "(i.e., numeric_op len field=00)". Obviously, if you decide to change this, then there are other places that need to be updated as well.
> 

Christoph: I would rather stick to the current version since it is exactly the expression that rfc5575bis uses. 

> ```
> 3.4.  Type 7 - ICMPv6 Type
> ```
> 
> The text wasn't super clear to me whether the a Type 3 componet could/should be specified to match protocol-value 58 as well as a Type 7 field. I would presume that either is allowed, but I was unsure whether it might be helpful to clarify this further.

Christoph: You may add a Type 3 component matching on protocol-value 58. However it is not needed, because you can only match ICMPv6 Type numbers when the packet actually is a ICMPv6 packet. This is also true with TCP/UDP port numbers ICMPv6 Code. We are actually reusing the text from rfc5575bis.


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