Re: [Idr] Barry Leiba's Discuss on draft-ietf-idr-flow-spec-v6-17: (with DISCUSS and COMMENT)
Barry Leiba <barryleiba@computer.org> Sun, 01 November 2020 15:29 UTC
Return-Path: <barryleiba@gmail.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 960303A0AF1; Sun, 1 Nov 2020 07:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NDR7q2vuPLrD; Sun, 1 Nov 2020 07:29:26 -0800 (PST)
Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 4228F3A0AE6; Sun, 1 Nov 2020 07:29:16 -0800 (PST)
Received: by mail-ua1-f53.google.com with SMTP id h26so685861uan.10; Sun, 01 Nov 2020 07:29:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GxXH5TQDOA84Wo0+UbCBjrtQoISWg8EyFer0jhvKKjg=; b=WAwqWq9wmGu//GXRGLjXdspNTU9TCwU5WqfpChqCExXlGS3cj5hEknn/NAtf2y5bny BQTsTS3l7OrGRWgch8WI8GW+0TAfUn5eUVygEuFlsAl87IMNnRrNxDA7QxytuZncdMEb NEPklYoxwghUVn8KXmGIR5d4QHgL10c4BVS4Ztr/pA0vv31qo40jr9ILKGhLU5W9f0t8 axMnJf3C0+S7Jh0C5lKlWqxvb2v+t8cf9KobdWKfhTHDcF89mqPC9EkP+4ohgHAZFKMI cTMkjthEol3XT/wTa609W1CLjqxNXIOekD3ihDIlHnpnr+0lt+4iY0zgCFhfDOaPLYjm +W0w==
X-Gm-Message-State: AOAM533Wlbfgg1ZKp5KWSUYvvznzt7ViPvzJjpZWMqdGUlluW8O6SNMn hxpauDjsq4aXqqTbekwo+m0F17aW6HCWY7Z7vNg=
X-Google-Smtp-Source: ABdhPJz5nxP2R/Bz56CxGb+WYaSDMpMl3nqQ+HAqwhkcgPOX4Qz2w9T/twSJEaNTtenGQZjfDExA/4AhAKxR5xa8NyU=
X-Received: by 2002:ab0:2409:: with SMTP id f9mr1803523uan.91.1604244555101; Sun, 01 Nov 2020 07:29:15 -0800 (PST)
MIME-Version: 1.0
References: <160419942295.32103.6403833617114377383@ietfa.amsl.com> <024901d6affd$dd6eef70$984cce50$@ndzh.com>
In-Reply-To: <024901d6affd$dd6eef70$984cce50$@ndzh.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Sun, 01 Nov 2020 10:29:03 -0500
Message-ID: <CALaySJ+FKg_zqCmvuhGwTLWNhepKS6GX7MoQfv2iSR+Sg29HCQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: Jie Dong <jie.dong@huawei.com>, The IESG <iesg@ietf.org>, aretana.ietf@gmail.com, draft-ietf-idr-flow-spec-v6@ietf.org, idr@ietf.org, idr-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d6f86605b30d4a67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XMP6uAAgViEwpbmkh5Bf6fmlmHo>
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 15:29:29 -0000
Ahhhhh, I see now! Yes, the issue is that citations aren’t allowed in the abstract, but without the citation things are very confusing. The new text in -18 makes it clear, and we can let he RFC Editor determine the best way to put it into the final RFC. On the address matching comment: [Sue: The flexibility seemed to be important to the operators. We can recheck with the WG if you wish.] I’ll leave it to your judgment. I always prefer when protocols have a single, well-defined way to do a function such as “match all”... but my comment is non-blocking, and I don’t need to discuss it further. Thanks for the responses, and thanks, Christoph, for making the changes and posting a revised I-D. I’m off to update my ballot now. Barry On Sat, Oct 31, 2020 at 11:20 PM 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] > 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.] > > >
- [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