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 document proposes lower than best effort service and discusses its implementation using Diffserv techniques.
It is generally in good shape, but there are two parts which could be clarified from a transport viewpoint.

First, Section 3 mentions : "Since
   LE traffic could be starved completely for a longer period of time,
   transport protocols or applications (and their related congestion
   control mechanisms) SHOULD be able to detect and react to such a
   starvation situation. "

This is an important point for such a service. Applications and/or transport protocols that are intended to be used with this service should be capable of supporting long losses of connectivity that may cause connections to fail. The document should strongly recommend to only use this service with applications/protocols that are capable of resuming an aborted data transfert. A regular TCP connection is usually not capable of doing this and thus using the service correctly requires more than simply tagging the packets sent by a given TCP connection with the chose DSCP.

Later, the document states "   While it is desirable to achieve a quick resumption of the transfer
   as soon as resources become available again, it may be difficult to
   achieve this in practice. "

I'm not personally convinced that a quick resumption of the transfer is the best approach to deal with periods where no LE packet is forwarded by the network. If a connection using LE fails, it does not seem to be appropriate to try to resume it immediately. It is likely that an approach like exponential backoff could make sense to avoid trying to restart such connections too early. 

Second, there is a small discussion of ECN in section 4: "   Since congestion control is also useful within the LE traffic class,
   Explicit Congestion Notification [RFC3168] SHOULD be used for LE
   packets, too."

Does this imply that LE packets SHOULD also be ECT capable packets, i.e. when a transport protocol is used to provide LE service, it should also support ECN or is this requirement weaker ?

Finally, Section 9 discusses the Multicast considerations. It mentions the utilisation of forward error correction schemes. One risk with FEC combined with LE is that FEC increases the amount of data that needs to be transferred and thus consumes ressources in non-congested parts of the network for packets that will be discarded downstream during periods of congestion. If there are simulation or measurement results that demonstrate that combining FEC and LE provides good results, it would be interesting to cite those results.