Last Call Review of draft-ietf-payload-rtp-ttml-02
review-ietf-payload-rtp-ttml-02-genart-lc-housley-2019-09-27-00

Request Review of draft-ietf-payload-rtp-ttml
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-10-10
Requested 2019-09-26
Draft last updated 2019-09-27
Completed reviews Genart Last Call review of -02 by Russ Housley (diff)
Genart Telechat review of -03 by Russ Housley
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-payload-rtp-ttml-02-genart-lc-housley-2019-09-27
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/-FHZXJQ-_B7H9yoxSBPh6gGsae8
Reviewed rev. 02 (document currently at 03)
Review result Ready with Issues
Review completed: 2019-09-27

Review
review-ietf-payload-rtp-ttml-02-genart-lc-housley-2019-09-27

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-payload-rtp-ttml-02
Reviewer: Russ Housley
Review Date: 2019-09-27
IETF LC End Date: 2019-10-10
IESG Telechat date: Unknown

Summary: Ready with Issues

Major Concerns:

Section 6 says:

   ...  An additional requirement if best-effort service is being
   used is users of this payload format MUST monitor packet loss to
   ensure that the packet loss rate is within acceptable parameters.

This MUST statement is very vague.  What does an implementer do?  Is
RFC 8083 (which is referenced in the following paragraph) the only way
to meet this MUST statement?  If so, please be very specific.

Please review Section 7.1; I suspect that RFC 2119 language is intended.


Minor Concerns:

Section 2 says:

   Unless otherwise stated, the term "document" is used in this draft to
   refer to the TTML document being transmitted in the payload of the
   RTP packet(s).

Please consider what this will say when it becomes an RFC.  The use of
"draft" will no longer be appropriate, and the use of "document" would
result in a very difficult sentence.  I propose:

   Unless otherwise stated, the term "document" refers to the TTML
   document being transmitted in the RTP payload.

Section 2 also says:

   Where the term "word" is used in this draft, it is to refer to byte
   aligned or 32-bit aligned words of data in a computing sense and not
   to refer to linguistic words that might appear in the transported
   text.

Again, "draft" is not appropriate once this becomes an RFC.  I suggest:

   The term "word" refers to byte aligned or 32-bit aligned words of
   data; it does not refer to linguistic words that might appear in the
   TTML document.

Section 2: Your reference to BCP 14 does not include "NOT RECOMMENDED".
Please use:

   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.

Section 4.1 says:

   User Data Words: integer number of data words

I suspect that negative integers and zero are not allowed.

Section 4.2.1.2.1.3 says:

   A processor profile (X) is compatible with the processor profile in
   this document (P) if X includes all the features and extensions in P,
   identified by their character content, and the "value" attribute of
   each is at least as restrictive as the "value" attribute of the
   feature or extension in P that has the same character content.  The
   term "restrictive" here is as defined in [TTML2] Section 6.

The use of "document" does not follow the discussion in Section 2.
I suggest:

   A given processor profile is compatible with the processor profile
   specified here if the given profile includes all the features and
   extensions, identified by their character content, and the "value"
   attribute of each is at least as restrictive as the "value" attribute
   of the feature or extension specified here using the same character
   content.  The term "restrictive" here is as defined in Section 6
   of [TTML2].

Nits:

Section 6 says:

   Congestion control for RTP SHALL be used in accordance with RFC 3550
   [RFC3550], and with any applicable RTP profile: e.g., RFC 3551
   [RFC3551].

I suggest the elimination of some redundancy:

   Congestion control for RTP SHALL be used in accordance with [RFC3550],
   and with any applicable RTP profile, such as [RFC3551].

Section 7.2: s/Section 3 of RFC 4855 [RFC4855]/Section 3 of [RFC4855]/