Subject: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-fecframe-ext-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Oct 2018 18:00:44 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tsvwg-fecframe-ext-06: No Objection

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-tsvwg-fecframe-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I tried to deduplicate my comments with the ones already in the
datatracker.

Section 1

It seems like the executive summary of this document would be "now you can
allocate FEC Encoding IDs that use sliding windows".  It might be helpful
to mention explicitly that the use of a sliding window is indicated through
the Encoding ID, with no other signaling.

Section 2

It might be helpful to indicate that a Payload ID includes positional
information as opposed to just content-type information.

Thank you for providing the summary in Section 3!

Section 5.3

   o  MUST define the management of the decoding window, consisting of a
      system of linear equations (in case of a linear FEC code);

I don't think this is the right way to phrase things; it implies that the
system of linear equations is always the information needed to manage the
decoding window, then trying to walk back that statement in a
parenthetical.  It seems better to just state the hard requiremnt for
window management, and make a separate sentence for what this means in the
linear system case.

Section 10

While I agree with the claim that the the security considerations are
basically unchanged for block-based and sliding-window FEC schemes, I do
find the security considerations of RFC 6363 to be slightly lacking.
In particular, its list of possible attack goals seem to omit some
possibilities that come up pretty often, like trying to corrupt source
flows to modify the receiver application's behavior (as opposed to just
denying service) and the arguably degenerate attack of just dropping lots
of traffic (for denial of service).
It's unclear that any of these are significant enough to merit specific
mention in this document, though.

Section 13

              This document being an extension to [RFC6363], the authors
   would also like to thank Mark Watson as the main author this RFC.

nit: "main author of that RFC" (noting in particular the "that", since
the "of" was already mentioned)