Subject: [AVTCORE] Genart last call review of draft-ietf-payload-rtp-ttml-02

From: Russ Housley via Datatracker <[email-masked]>
Date: Fri, 27 Sep 2019 13:26:40 -0700

Reviewer: Russ Housley
Review result: Ready with Issues

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]/