Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr-flow-spec-v6-17: (with DISCUSS and COMMENT)
Christoph Loibl <c@tix.at> Sun, 01 November 2020 10:01 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 BCE2A3A1011; Sun, 1 Nov 2020 02:01:53 -0800 (PST)
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 U0WYHhJd6cUu; Sun, 1 Nov 2020 02:01:49 -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 64E943A1010; Sun, 1 Nov 2020 02:01:46 -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=m5Z0d8JMyhmYcit5gnjvpd/JZWVvJ4HpHRQELsImalQ=; b=QnadqP/1JsoZgxGBCF0btlYtny 4iJ5q6YfwNEa7tyPlroAWL2/CGq6izznq4iIARKRFUX8TxTjP9sml/CwCbfcOOYfu+N9N74315EFl nzZjO5e8qpIj18625zvVeBpJdEdW+MD9Tusz1ey18Udle0uOkf78WHWC/c3/yuuHZPjTKnIZ/9ytP Rb5G+Hxjsci3iMdWa4atkbbAcTG92DEF3Jccfn0tYE1PXLYkuKtMlN1ZLhlIAetNBd723aR+Gg++U vsc1nbrvVduMAnxg43Hvu14Tga9UrASseDeFmMoNci9frHkQyoA7HJZKQW2IXuqNLaFBuoDx8lDQp g2TwrEew==;
Received: from 213-225-7-67.nat.highway.a1.net ([213.225.7.67] helo=[192.168.43.10]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kZAB9-000AVV-7d; Sun, 01 Nov 2020 11:01:41 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <30EF85A5-A697-43A7-852A-58B50CFE8D3F@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E730F88-CCEA-4C1E-B5D1-89F449B6EAC4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Sun, 01 Nov 2020 11:01:35 +0100
In-Reply-To: <024901d6affd$dd6eef70$984cce50$@ndzh.com>
Cc: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-flow-spec-v6@ietf.org, idr@ietf.org
To: Susan Hares <shares@ndzh.com>
References: <160419942295.32103.6403833617114377383@ietfa.amsl.com> <024901d6affd$dd6eef70$984cce50$@ndzh.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Sun, 01 Nov 2020 11:01:39 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KaUqSVGAFg1B_pLV8QNSuDUexQ8>
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 10:01:54 -0000
Hi Barry and Sue, Thank you for reviewing the document. Indeed the Abstract, after removing the references, got confusing I edited the textual reference back into the document as suggested by Sue. The issues raised in your review are tracked via Github: https://github.com/stoffi92/draft-ietf-idr-flow-spec-v6/issues/57 I just uploaded a -18 that fixes the Abstract (Discuss-Item) along with most of the minor and editorial issues that you raised in the way you and Sue suggested. Please see the diff on datatracker and the commits on Github: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-flow-spec-v6-17&url2=draft-ietf-idr-flow-spec-v6-18 Cheers Christoph -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 01.11.2020, at 04:19, Susan Hares <shares@ndzh.com> wrote: > > 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 <mailto:noreply@ietf.org>] > Sent: Saturday, October 31, 2020 10:57 PM > To: The IESG > Cc: draft-ietf-idr-flow-spec-v6@ietf.org <mailto:draft-ietf-idr-flow-spec-v6@ietf.org>; idr-chairs@ietf.org <mailto:idr-chairs@ietf.org>; idr@ietf.org <mailto:idr@ietf.org>; Jie Dong; aretana.ietf@gmail.com <mailto:aretana.ietf@gmail.com>; jie.dong@huawei.com <mailto: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.] > > > _______________________________________________ > Idr mailing list > Idr@ietf.org <mailto:Idr@ietf.org> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
- [Idr] Barry Leiba's Discuss on draft-ietf-idr-flo… Barry Leiba via Datatracker
- Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr… Susan Hares
- Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr… Christoph Loibl
- Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr… Barry Leiba