From: James Sandford <james.sandford@bbc.co.uk>
To: Russ Housley <housley@vigilsec.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "ietf@ietf.org" <ietf@ietf.org>, "avt@ietf.org" <avt@ietf.org>,
 "draft-ietf-payload-rtp-ttml.all@ietf.org"
 <draft-ietf-payload-rtp-ttml.all@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-payload-rtp-ttml-02
Thread-Index: AQHVdXHh4NeQyOOEuUO8IHChUjOhfadQmbI3
Date: Tue, 8 Oct 2019 10:24:28 +0000
Message-ID: <734752AF0E88364D983373FE5CEFED5770DE00B7@bgb01xud1001>
References: <156961600000.25061.6985668960752306671@ietfa.amsl.com>
In-Reply-To: <156961600000.25061.6985668960752306671@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/silObHqrLKU6gOZiO7rhkMhzDmc>
Subject: Re: [AVTCORE] Genart last call review of
 draft-ietf-payload-rtp-ttml-02
Precedence: list

Hello,=0A=
I've uploaded version 03 which addresses these comments and minor comments =
from the AD (Barry) and Document Shepherd (Roni). =0A=
=0A=
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/=0A=
=0A=
Regards,=0A=
James=0A=
=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
James Sandford=0A=
R&D Project Engineer=0A=
=0A=
BBC Research and Development=0A=
5th Floor=0A=
Dock House=0A=
MediaCityUK=0A=
Salford=0A=
M50 2LH=0A=
=0A=
Tel: 030304 (09549)=0A=
Web: http://www.bbc.co.uk/rd=0A=
=0A=
________________________________________=0A=
From: Russ Housley via Datatracker [noreply@ietf.org]=0A=
Sent: 27 September 2019 21:26=0A=
To: gen-art@ietf.org=0A=
Cc: ietf@ietf.org; avt@ietf.org; draft-ietf-payload-rtp-ttml.all@ietf.org=
=0A=
Subject: Genart last call review of draft-ietf-payload-rtp-ttml-02=0A=
=0A=
Reviewer: Russ Housley=0A=
Review result: Ready with Issues=0A=
=0A=
I am the assigned Gen-ART reviewer for this draft. The General Area=0A=
Review Team (Gen-ART) reviews all IETF documents being processed=0A=
by the IESG for the IETF Chair.  Please treat these comments just=0A=
like any other last call comments.=0A=
=0A=
For more information, please see the FAQ at=0A=
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.=0A=
=0A=
Document: draft-ietf-payload-rtp-ttml-02=0A=
Reviewer: Russ Housley=0A=
Review Date: 2019-09-27=0A=
IETF LC End Date: 2019-10-10=0A=
IESG Telechat date: Unknown=0A=
=0A=
Summary: Ready with Issues=0A=
=0A=
Major Concerns:=0A=
=0A=
Section 6 says:=0A=
=0A=
   ...  An additional requirement if best-effort service is being=0A=
   used is users of this payload format MUST monitor packet loss to=0A=
   ensure that the packet loss rate is within acceptable parameters.=0A=
=0A=
This MUST statement is very vague.  What does an implementer do?  Is=0A=
RFC 8083 (which is referenced in the following paragraph) the only way=0A=
to meet this MUST statement?  If so, please be very specific.=0A=
=0A=
Please review Section 7.1; I suspect that RFC 2119 language is intended.=0A=
=0A=
=0A=
Minor Concerns:=0A=
=0A=
Section 2 says:=0A=
=0A=
   Unless otherwise stated, the term "document" is used in this draft to=0A=
   refer to the TTML document being transmitted in the payload of the=0A=
   RTP packet(s).=0A=
=0A=
Please consider what this will say when it becomes an RFC.  The use of=0A=
"draft" will no longer be appropriate, and the use of "document" would=0A=
result in a very difficult sentence.  I propose:=0A=
=0A=
   Unless otherwise stated, the term "document" refers to the TTML=0A=
   document being transmitted in the RTP payload.=0A=
=0A=
Section 2 also says:=0A=
=0A=
   Where the term "word" is used in this draft, it is to refer to byte=0A=
   aligned or 32-bit aligned words of data in a computing sense and not=0A=
   to refer to linguistic words that might appear in the transported=0A=
   text.=0A=
=0A=
Again, "draft" is not appropriate once this becomes an RFC.  I suggest:=0A=
=0A=
   The term "word" refers to byte aligned or 32-bit aligned words of=0A=
   data; it does not refer to linguistic words that might appear in the=0A=
   TTML document.=0A=
=0A=
Section 2: Your reference to BCP 14 does not include "NOT RECOMMENDED".=0A=
Please use:=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and=0A=
   "OPTIONAL" in this document are to be interpreted as described in=0A=
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all=0A=
   capitals, as shown here.=0A=
=0A=
Section 4.1 says:=0A=
=0A=
   User Data Words: integer number of data words=0A=
=0A=
I suspect that negative integers and zero are not allowed.=0A=
=0A=
Section 4.2.1.2.1.3 says:=0A=
=0A=
   A processor profile (X) is compatible with the processor profile in=0A=
   this document (P) if X includes all the features and extensions in P,=0A=
   identified by their character content, and the "value" attribute of=0A=
   each is at least as restrictive as the "value" attribute of the=0A=
   feature or extension in P that has the same character content.  The=0A=
   term "restrictive" here is as defined in [TTML2] Section 6.=0A=
=0A=
The use of "document" does not follow the discussion in Section 2.=0A=
I suggest:=0A=
=0A=
   A given processor profile is compatible with the processor profile=0A=
   specified here if the given profile includes all the features and=0A=
   extensions, identified by their character content, and the "value"=0A=
   attribute of each is at least as restrictive as the "value" attribute=0A=
   of the feature or extension specified here using the same character=0A=
   content.  The term "restrictive" here is as defined in Section 6=0A=
   of [TTML2].=0A=
=0A=
Nits:=0A=
=0A=
Section 6 says:=0A=
=0A=
   Congestion control for RTP SHALL be used in accordance with RFC 3550=0A=
   [RFC3550], and with any applicable RTP profile: e.g., RFC 3551=0A=
   [RFC3551].=0A=
=0A=
I suggest the elimination of some redundancy:=0A=
=0A=
   Congestion control for RTP SHALL be used in accordance with [RFC3550],=
=0A=
   and with any applicable RTP profile, such as [RFC3551].=0A=
=0A=
Section 7.2: s/Section 3 of RFC 4855 [RFC4855]/Section 3 of [RFC4855]/=0A=
=0A=
=0A=