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

[Susan Hares <[e-mail]>]

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:[e-mail]] 
Sent: Saturday, October 31, 2020 10:57 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; Jie Dong; [e-mail]; [e-mail]
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.]