This Internet Draft describes how to carry transport objects in some notion of "real time" (in this case: with transmission-side enforced time bounds) of a UDP-based transport protocol via unicast or multicast to one or more receivers. The underlying network may (but need not) be unidirectional in nature. The protocol uses the layered coding transport (LCT) and, optionally, the FEC building block (as well as FLUTE) defined earlier in the RMT WG. The draft itself focuses on the exact usage along with parameterisation of these underlying building blocks, which makes it partly very hard to read (and validate). At this point, I have not carried out a detailed analysis if all the usages of the underlying building blocks are correct and consistent, as there are other issues to be addressed first.

The draft is an individual contribution that is linked to work in other standards bodies and does not seem to have undergone any review process in the IETF so far.  It is at least not linked to a working group, and also the terminology used in some places suggests this.

This review is broader than just a transport area review as many issues come to mind. But gen-art and secdir reviews are expected to provide more detail on the points raised.

Overall, the draft could be seen as heading in the right direction to achieve what the authors are after: transmitting video segments (of DASH-coded media streams) or other files along with metadata across a packet channel a possibly large and heterogeneous receiver group. But it has still a long way to go.

Terminology:
- "Transport" is understood by some standards organisation as the medium to carry bits (referred to as L1/L2 in the IETF) but has a different meaning in the IETF, namely end-to-end adaptation of a (best effort) service to the application needs. Insofar, the title is already misleading as it uses the term transport twice and in both meanings. Suggest to change one occurrence to network (subsuming the lower layers).
- define "transport buffer" (and possibly other terms in a terminology section)
- sect 5.2 states " beyond the scope of this transport standard". The present target of the spec is "Informational", so it won't be a standard.
- the actual "standard" text pieces should use proper RFC 2026 terminology

Structure:
- section 9 introduces ROUTE concepts; put this first. The reader should understand what this is all about before worrying about individual parameters and the like.
- section 10 needs more context 

Technical:
- The document needs a clear scope and applicability statement. The technologies presented are not feasible for use in the open Internet. See below.
- Figure 1 seems incorrect. At best, you can carry a DASH segment on top of ROUTE, but certainly not DASH as ROUTE does perform HTTP-req/rsp-style operation with receiver side adaptation.
- The document says almost *nothing* about congestion control. It specifies how many bits of congestion information to use, but this boils down to saying that a 32 bit number (if I am not mistaken) shall be used. No further guidance is given, let alone algorithms or mechanisms mandated. 
- The use of the CCI field is unclear: how will the earliest presentation time relevant be used?
- sect. 5.1 states that "Congestion control is thus sender-drive in ROUTE" but the entire document doesn't seem to say anything more.
- Identifying a connection by means of IP address/port pairs alone many not guarantee uniqueness if the sender (the entity choosing the id) is behind a NAT.
- sect. 5.3 seems to suggest to exclusively rely on application information for pacing packet transmission, which seems at odds with congestion control.
- sect. 5.4 doesn't seem to account for the one-way delay from sender to receiver, but could still be ok
- sect. 6: what does graceful operation in case of reception of unrecognised packet mean when the application is to be informed? Given stray packets, possibly Internet background radiation, attacks, etc. this statement seems to assume operation in a protected environment.
- sect. 6.1 also seems to lack failure handling
- for carrying ROUTE over TCP, which is mentioned in the security considerations, a framing would be needed (and possibly connection setup and teardown procedures)
- the security considerations, for UDP, point to DTLS. But this won't work with multicasting and it won't work with unidirectional networks either

Editorial:
- The code points for the CP should be explained, not just listed, or referenced properly
- for curiosity: do you need anything but ASCII so that a reference to "alphanumeric data" would require character set considerations?
- explain the session metadata and their purposes, don't just list them
- don't describe math just in text but provide equations; this may also apply to values in fields (such as overhead (o))
- improve text clarity and use shorter sentences (e.g. maxExpiresDelta, but not just there)
- the paper has minor grammar issues (missing "the" or "a" in many places)
- sect. 4.1.2: "The content encoding defined in the presence RFC is gzip."  What does the "present RFC" refer to?
- sect 4.3 seems insufficient: MIME can be used in many different ways
- sect 5.5: what is a "protected repair flow"?
- sect 6.3.1 should provide a formal definition 


Interop:
- What are the implications of values being undefined? e.g. the minimum transport buffer?  Handling?
- what happens if maxTransportSize is missing?
- in general the draft doesn't say much about failure/error handling
- sect. 8: would a registration mechanism be needed for application profiles? Who would manage this?