Change:
The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- <del> bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection, all but the first audio and video tracks will be marked as bundle-only, and candidates will only be gathered for N media streams, where N is the number of distinct media types.  When talking to a non-BUNDLE- aware endpoint, only the non-bundle-only streams will be negotiated.  This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. </del> <ins> bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: The first media section of each type (audio, video, or application) will contain transport parameters, which will allow an answerer to unbundle that section.  The second and any subsequent media section of each type will be marked bundle-only. The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio and video can still be negotiated in legacy cases. All media sections will contain transport parameters; none will be marked as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. Only the first media section will contain transport parameters; all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST

Discussion:
LGTM
Holding my review until Martin's comments are addressed
lgtm with comments above
seems clear that there is one: Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. The effect of this is that the browser offers all m= sections as one BUNDLE group. However, whether the m= sections are bundle-only or not depends on the BUNDLE policy. seems clear that "balanced" means >1 The application will BUNDLE all media streams of the same type together. That is, if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection, all but the first audio and video tracks will be marked as bundle-only, and candidates will only be gathered for N media streams, where N is the number of distinct media types. When talking to a non-BUNDLE-aware endpoint, only the non-bundle-only streams will be negotiated. This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. Justin and EKR believe the number should always be 1. Need to fix the text to make this clear.
Right, seems like we need to change 4.1.1 to say the application will try to BUNDLE all media streams, but can fall back to the unbundled case where audio, video, and data are on separate transports. We should also have a sentence somewhere that indicates that only a single bundle group is ever offered.
Control of # of bundle groups is left as something for the future; we would need an additional policy, or some other thing to frob, perhaps on rtpsender.
First I think browsers need to be able to correctly respond to more than one bundle (which may mean rejecting the bundle), but I want to leave it open that an browser impelmetion is allowed to create more than one bundle. If you read the mux atributes draft you will see there are many cases where the browser might choose to create more than one bundle.
Which section?
Well if you ever want to do any of things that are not allowed to be in the same bundle, you end up wanting two bundles.