Hello, I've uploaded version 03 which addresses these comments and minor comments from the AD (Barry) and Document Shepherd (Roni). https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ Regards, James ========== James Sandford R&D Project Engineer BBC Research and Development 5th Floor Dock House MediaCityUK Salford M50 2LH Tel: 030304 (09549) Web: http://www.bbc.co.uk/rd ________________________________________ From: Russ Housley via Datatracker [noreply@xxxxxxxx] Sent: 27 September 2019 21:26 To: gen-art@xxxxxxxx Cc: ietf@xxxxxxxx; avt@xxxxxxxx; draft-ietf-payload-rtp-ttml.all@xxxxxxxx Subject: Genart last call review of draft-ietf-payload-rtp-ttml-02 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]/
