Subject: Genart telechat review of draft-ietf-payload-rtp-ttml-03

From: Russ Housley via Datatracker <[email-masked]>
Date: Fri, 11 Oct 2019 10:40:14 -0700

Reviewer: Russ Housley
Review result: Ready with Nits

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-03
Reviewer: Russ Housley
Review Date: 2019-10-11
IETF LC End Date: 2019-10-10
IESG Telechat date: 2019-10-17

Thank you for addressing my comments on the previous version of this
Internet-Draft.

Summary: Ready with Nits

Major Concerns:

None.

Minor Concerns:

None.

Nits:

My guess is that the second paragraph in Section 7.1 uses "should"
because it is asking implementors to think about these things when
selecting a clock rate.  I expected this section to be talking about
the payload format parameters, not implementation considerations.  I
am not sure, but this paragraph might be more impactful elsewhere.  

In section 4.2.1.1 and 4.2.1.2.1.2, should the blocks of XML be
enclosed between '<CODE BEGINS>' and '<CODE ENDS>' lines to make it
very clear that the Simplified BSD License applies here?

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 14 Oct 2019 13:41:43 -0400

Russ, thanks for your reviews of this document. James, thanks for incorporating updates based on Russ’s prior review. I don’t have strong feelings about either of Russ’s points below but it would be good to get a response. I entered a No Objection ballot.

Alissa

> On Oct 11, 2019, at 1:40 PM, Russ Housley via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Russ Housley
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: James Sandford <[email-masked]>
Date: Tue, 15 Oct 2019 10:17:07 +0000

Hello,
Thank you for the further feedback. 

In an earlier draft we had the second paragraph of section 7.1 elsewhere in the document. I believe it was in section 4.2.1.2 which discusses, amongst other things, how the TTML document timing relates to the RTP timestamps. We concluded that the document was easier to understand when all of the information related to clock rate was in the one section. If this goes against convention, I'm happy to move the second paragraph to another part of the document. But from the position of making the document easy to understand, leaving the information in one place might be best.

With regards to <CODE BEGINS> <CODE ENDS>, I understand that these are defined in the TLP for the purpose of identifying Code Components that aren't already one of the types listed in the accompanying Code Components document and that the Code Components document includes XML. I also see in this thread that the CODE BEGINS notation is seen as optional https://www.rfc-editor.org/pipermail/rfc-interest/2016-December/009782.html . I would prefer to not use the CODE BEGINS notation as, at a glance, it looks quite similar to XML itself and may be confusing. Furthermore, the understanding of the meaning of the CODE BEGINS notation requires the reader to read the TLP which already clearly specifies that XML is considered a Code Component. I believe that, in this case, CODE BEGINS is redundant and would make the document more confusing rather than less. 

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 [[email-masked]]
Sent: 11 October 2019 18:40
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart telechat review of draft-ietf-payload-rtp-ttml-03

Reviewer: Russ Housley

Summary: Ready with Nits

Major Concerns:

None.

Minor Concerns:

None.

Nits: