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

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>