[Idr] Genart last call review of draft-ietf-idr-flow-spec-v6-17

Dale Worley via Datatracker <noreply@ietf.org> Sun, 25 October 2020 20:08 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 527AE3A15D9; Sun, 25 Oct 2020 13:08:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: draft-ietf-idr-flow-spec-v6.all@ietf.org, last-call@ietf.org, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160365652729.4261.691666404258157493@ietfa.amsl.com>
Reply-To: Dale Worley <worley@ariadne.com>
Date: Sun, 25 Oct 2020 13:08:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZMfCd9lgO5WY1YucYNdXN52w9L0>
Subject: [Idr] Genart last call review of draft-ietf-idr-flow-spec-v6-17
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Oct 2020 20:08:47 -0000

Reviewer: Dale Worley
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document:  draft-ietf-idr-flow-spec-v6-17
Reviewer:  Dale R. Worley
Review Date:  2020-10-25
IETF LC End Date:  2020-10-21
IESG Telechat date:  2020-11-05


    This draft is ready for publication as a Standards Track RFC.

Nits/editorial comments:

3.1.  Type 1 - Destination IPv6 Prefix
3.2.  Type 2 - Source IPv6 Prefix

Unlike IPv4, it is plausible that a set of flows could be determined
by two contiguous sections of an address, e.g., an initial prefix and
a subset of bits within an embedded IPv4 address.  By
draft-ietf-idr-rfc5575bis-26 section 4.2, an IPv6 flow specification
may not contain two Destination IPv6 Prefix or two Source IPv6 Prefix
components, so this type of selection cannot be specified.

4.  Ordering of Flow Specifications

   If the offsets are not equal, the lowest offset has
   precedence, as this flow matches the most significant bit.

"as this flow" should be "as this flow specification"

5.  Validation Procedure

      a) A destination prefix component with offset=0 is embedded in the
      Flow Specification

I note that this requirement has no functional effect, as a
destination prefix with length = 0 can always be added to a flow
specification without effect.  However, this observation also applies
to IPv4 flow specifications, so I assume it has been given due