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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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:[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.]
>
>
>