Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr-flow-spec-v6-17: (with DISCUSS and COMMENT)

Susan Hares <shares@ndzh.com> Sun, 01 November 2020 03:20 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 96CBE3A0E24; Sat, 31 Oct 2020 20:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 F4JDn2xWO0KE; Sat, 31 Oct 2020 20:20:11 -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 BE3D53A0E25; Sat, 31 Oct 2020 20:20:10 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.115.222;
From: "Susan Hares" <shares@ndzh.com>
To: "'Barry Leiba'" <barryleiba@computer.org>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-idr-flow-spec-v6@ietf.org>, <idr-chairs@ietf.org>, <idr@ietf.org>, "'Jie Dong'" <jie.dong@huawei.com>, <aretana.ietf@gmail.com>
References: <160419942295.32103.6403833617114377383@ietfa.amsl.com>
In-Reply-To: <160419942295.32103.6403833617114377383@ietfa.amsl.com>
Date: Sat, 31 Oct 2020 23:19:46 -0400
Message-ID: <024901d6affd$dd6eef70$984cce50$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHTIzNDgjxe2cDAy3YJUalbocLGKam5sfNA
Content-Language: en-us
X-Antivirus: AVG (VPS 201031-6, 10/31/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1QrpnWySgKtn8vBGaKkivoMblEo>
Subject: Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr-flow-spec-v6-17: (with DISCUSS and 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: Sun, 01 Nov 2020 03:20:13 -0000

Barry: 

It's an editorial error rather than a simple typo.   We edited the original abstract to provide a shorter text after comments from Alvaro, and it is now confusing.   
-----------
Old/
   Dissemination of Flow Specification Rules provides a Border Gateway
   Protocol extension for the propagation of traffic flow information
   for the purpose of rate limiting or filtering IPv4 protocol data
   packets.   

    This document extends I-D.ietf-idr-rfc5575bis with IPv6
   functionality.  It also updates I-D.ietf-idr-rfc5575bis by changing
   the IANA Flow Spec Component Types registry.
/
New/
   The Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis] 
   provides an Border Gateway Protocol extension for the propagation of traffic flow information
   for the purpose of rate limiting or filtering IPv4 protocol data
   packets. 

   This document extends I-D.ietf-idr-rfc5575bis with IPv6
   functionality.  It also updates I-D.ietf-idr-rfc5575bis by changing
   the IANA Flow Spec Component Types registry.
/ 

Thanks for catching this error early.   We'll quickly change that error. 

The remainder of the errors are commented below. 

Thank you for your early comments. 

Sue  

-----Original Message-----
From: Barry Leiba via Datatracker [mailto:noreply@ietf.org] 
Sent: Saturday, October 31, 2020 10:57 PM
To: The IESG
Cc: draft-ietf-idr-flow-spec-v6@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Jie Dong; aretana.ietf@gmail.com; jie.dong@huawei.com
Subject: Barry Leiba's Discuss on draft-ietf-idr-flow-spec-v6-17: (with DISCUSS and COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-idr-flow-spec-v6-17: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be extremely straightforward: either there’s a typo... or I simply don’t understand.  In the Abstract:

   Dissemination of Flow Specification Rules provides a Border Gateway
   Protocol extension for the propagation of traffic flow information
   for the purpose of rate limiting or filtering IPv4 protocol data
   packets.

Is that supposed to say “IPv6”?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few minor comments:

— Section 3.1 —

   The offset has been defined  to allow for flexible matching on part of the IPv6 address where it
   is required to skip (don't care) of N first bits of the address.

I can’t parse this sentence, nor make sense of the parenthetical.  Can you reword it?

[Sue:  New/ The offset has been defined to allow for flexible matching to portions of an 
            IPv6 address where one is required to skip over the first N bits of the address. 
           (These bits skipped are often indicated as "don’t care bits.) 
        / 


   In the case Length minus Offset is 0 every address matches.  Length
   MUST always be in the range 0-128 and Length minus Offset MUST always
   be 0 or more, otherwise this component is malformed.

Is there actually value in allowing 129 ways to match every address (length=offset=0, length=offset=1, length=offset=87, and so on)?  If not, it seems less prone to error to say that length=offset=0 matches every address, and otherwise length MUST be greater than offset or the component is malformed.
 No?
[Sue:  The flexibility seemed to be important to the operators.   We can recheck with the 
           WG if you wish.] 

— Section 3.8.1 —

   Neither for the destination prefix pattern (length - offset = 32 bit)
   nor for the source prefix pattern (length - offset = 40 bit) any
   padding is needed (both patterns end on a octet boundary).

This isn’t grammatical.  How about this?:

NEW
   Padding is not needed either for the destination prefix pattern
   (length - offset = 32 bit) or for the source prefix pattern
   (length - offset = 40 bit), as both patterns end on a octet
   boundary.
END

[Sue your changes seems reasonable to me.  I'll check that Alvaro is ok with the change.]