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

From: Adam Roach <[email-masked]>
Date: Tue, 09 Oct 2018 20:14:24 -0700

Adam Roach 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:
----------------------------------------------------------------------

Thanks for the work involved in developing this document. I have only a handful
of editorial comments.

---------------------------------------------------------------------------

Abstract:

>  in a backward compatible way.  During multicast/broadcast real-time

Nit: "...backward-compatible..."

---------------------------------------------------------------------------

§1:

>  the transport or application layer, is an efficient technique to

Nit: remove comma

>  separately defined FEC schemes.  Any CDP defined according to the

Nit: "...separately-defined..."

---------------------------------------------------------------------------

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in BCP
>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>  capitals, as shown here.

It is not necessary to include boilerplate from both RFC 2119 and RFC 8174.
Please remove the first of these two paragraphs.

---------------------------------------------------------------------------

§3:

>  an ADU to symbols mapping process that is FEC Scheme specific (see

"...ADU-to-symbols..."

"...FEC-Scheme..."

>  symbols.  After source symbol to ADU mapping, when lost ADUs are

"...source-symbol-to-ADU..."

>  o  ADUs to source symbols mapping: in order to manage variable size

"...ADUs-to-source-symbols..."

>     FEC Scheme dependant and must be defined in the associated

"...FEC-Scheme-dependent..."
(note both insertion of hyphens and spelling of "dependent")

>     prepended with a flow identifier (1 byte) during the ADU to source
>     symbols mapping (see above).  The flow identifiers are also shared

"...ADU-to-source-symbols..."

---------------------------------------------------------------------------

§4.2:

>       ADU to source symbols mapping as well as the encoding window

"...ADU-to-source-symbols..."

>       and MUST be detailed there.  Appendix A provides non normative

"...non-normative..."

---------------------------------------------------------------------------

Appendix A:

>  new ADU is available at the sender, after the ADU to source symbol

"...ADU-to-source-symbol..."