This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The draft discusses use cases for the Reliable and Available Wireless WG;
in fact, it "extends" on existing documents.

Being a use case document, the draft doesn't really have specific transport
related issues per se, but a few points below -- some of more general
nature -- are worth considering.

Maybe section 1 can avoid using the term transport in the context of the
underlying carrier network and use a different term more compatible with
IETF terminology instead. Link? Network? L2?

The document discussed quite a diverse set of use cases but does so at
very different depth and level of detail.  In one case, concrete requirements
are hinted at in terms of milliseconds of latency but no others mention these.
I understand that this is not a requirements document but if something is a
specific use case for RAW, maybe we can be more specific than saying data
needs to be carried within some time bound across a wireless link?  I believe
being more concrete may help the group decide which types of mechanisms are
to be applied for which use cases.

Section 5.2.2: With audiovisual communication having a long history in the
IETF, there is clearly an awareness of what it takes to do smooth playback
and synchronized playback: playout buffers. These, of course, would add 
latency, so the point made here is well taken but it should be put into the
context of A/V over packet networks.

When discussing especially the non-latency critical considerations
(e.g., in section 5.4.1), keep in mind that the IETF offers many protocols
that could quite easily cope with packet losses, add redundancy, also across
multiple paths.  These protocols operate above the link and IP layer,
typically at the transport layer or, e.g., with Application Layer Framing,
even at the application layer.  I would thus urge the authors to not have the
document suggest that certain mechanisms need to be addressed with the scope
of RAW or the layers below.  This would appear beyond scope of a use case
draft and also too limiting.

Finally, the document suddenly mentions security properties in section 9.4.
This appears inconsistent as such considerations likely apply to all other
use case as well and there may be little the RAW WG can do here (especially
when security is suggested to be end-to-end).

Nits:
-- articles missing in numerous places -> RFC Editor?
-- "communications system" -> "communication systems"
-- communication's requirements -> communication requirements
-- network's edge device -> network edge device
-- inter-network