I reviewed version -08 of the document.

The draft describes a system comprising two gateways and some elements of a protocol
between those two gateways.  A sender side gateways retrieves HAS streaming content,
i.e., media segments, from an HTTPS server, thus acting as a HAS client, and sends
these segments along with some metadata via IP multicast to a receiver gateway.  The
latter receives and stores ("caches") these and serves them to regular HAS clients,
thus acting as a HAS server.  The protocol between the two gateways is called MSYNC.

This draft has substantial issues (not just) from a transport layer perspective and
it is actually questionable how those can be addressed within the scope of the document.
Given the significance of the fundamental issues, I focus on those and leave details
aside.

Section 1 states that MSYNC is "simple" and as part of this simplicity does not do
"flow control".  The authors may mean "no congestion control" but it actually does
neither as the rest of the document confirms.  Reading further, the authors appear
to assume that a single provider is running this protocol within its own network
where it has full control of the network capacity and can set aside a capacity share
for exclusive use by MSYNC.  A number of examples of specific link layers are given,
and one may get the impression that the protocol is indeed targeted towards a single
link for a single IP hop, rather than a more complex IP network (even though slicing
or similar mechanisms could support setting aside dedicated capacity in an IP network
as well.  This also becomes evident also in section 3.6 in which it is said that 
packets should not exceed MTU size but no guidance is provided how to obtain it.
(I note that the max UDP datagram size has a typo.)

As this mix of system/protocol description obviously refers to a closed environment,
this begs the question why the IETF should bother dealing with this document in the
first place.  HAS is not defined in the IETF but the IETF has defined a number
of specifications for multicast transport (e.g., RFC 5740, RFC 5401 for NORM), which
could probably be used.  No discussion of any such existing solutions is given.
So, it would seem one could just achieve the intended goals by combining existing
technologies.

The draft does make reference to RTP (section 3.9) but remains very vague to silent
on, e.g., how to use payload types and how to perform encapsulation including
timestamps, etc.  Just referencing RFC 3551 alone is clearly insufficient.

The security considerations effectively state that no security is provided and that
this may be risky.  While this is not a security review, I consider this problematic,
especially since security building would appear to be available.

The spec appears vastly incomplete.  It seems that many details are missing to allow
two independent implementations to interoperate.

There are many nits but, focusing on one, I find the term "super object" to refer to
an "unterminated" object, i.e., one of unknown side, confusing, given the various uses
the term "super" has seen in distributed systems in the past (e.g., super peers). At
least the term isn't a good fit for what it refers to.

Also concerning terminology, it would be useful to stick to the terms used within the
Internet context, e.g., for multicast groups, we talk about joining and leaving, not
about attaching to them.

I consider the draft to be questionable in terms of scope for the IETF RFC publication
process as it is intended for closed networks only and does not consider substantial
IETF work.  With its technical flaws, its usefulness is questionable.  With this and
in light of the IPR disclosures related to this draft, I am wondering if the IETF
community should spend (more) cycles on it.  But I may miss some background or context
here.