Original text:
not meaningful in the JSEP context and MAY be discarded once they have been checked.  TODO The remaining lines are processed as follows: <del> The "c=" line MUST be parsed and stored. </del> [OPEN ISSUE: For example, because session-level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: <del> The "c=" line, if present, MUST be parsed as specified in RFC4566, Section 5.7, and its contents stored. </del>  The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.

Reviewer comments:
NAME is this OK? NAME
lgtm with the one comment above
Ignored is the wrong word to use here. The value is not used is true but ignored is just simply not true.
Hmm.... We're not checking it and not doing anything with it. I'm happy to use another word, but I'm going to need you to suggest one. , Cullen Jennings EMAIL wrote:
NAME please r+ if you are happy. NAME please merge if you are happy.
I really don't care but it like 1 of the 3 things I raised got fixed
I see I missed the trickle thing. What else is there? , Cullen Jennings EMAIL wrote:
Around line 2216 I had another change "SHOULD be ignored" to "is not used". I think we are running into the limitations of using github for review here.
Indeed, I think I missed it. , Cullen Jennings EMAIL wrote:
NAME I think this is ready to merge if you are still happy.
LGTM
lgtm with minor change
When JSEP recommends that lines are ignored (absent some syntax validation), it violates a rule in RFC 5245 regarding mismatch processing. 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section. Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft, since this is different to what 5245 says.
The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses: If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice- mismatch attribute in its answer. Not proceeding with ICE isn't an option here, and this is somewhat problematic with trickle ice (at least the initial 0.0.0.0 candidate), so I think ignoring makes sense.

Revised text:
not meaningful in the JSEP context and MAY be discarded once they have been checked. <ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to use "ice-mismatch" to indicate mismatches between "c=" and the candidate lines; because JSEP always uses ICE, "ice-mismatch" is not useful in this context. </ins> TODO The remaining lines are processed as follows:  [OPEN ISSUE: For example, because session-level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines:  <ins> As with the "c=" line at the session level, the "c=" line MUST be parsed according to RFC4566, Section 5.7, but its value is not used. </ins> The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.