Original text:
lines, as specified in RFC4566, Section 6, and RFC3264, Section 5.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </del> If the RtpTransceiver has a sendrecv or sendonly direction: An "a=msid" line, as specified in I-D.ietf-mmusic-msid, simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section.  The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In above, an m= section MUST be generated for it with the port set to zero and the "a=msid" line removed. <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST </del>  stay the same if they are present in the current description. Each "m=" and c=" line MUST be filled in with the port, protocol, lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is

Reviewer comments:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.

Revised text:
lines, as specified in RFC4566, Section 6, and RFC3264, Section 5.1.  For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.  If the RtpTransceiver has a sendrecv or sendonly direction: An "a=msid" line, as specified in I-D.ietf-mmusic-msid, simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In above, an m= section MUST be generated for it with the port set to zero and the "a=msid" line removed.  <ins> For RtpTransceivers that are not stopped, the "a=msid" lines MUST </ins> stay the same if they are present in the current description. Each "m=" and c=" line MUST be filled in with the port, protocol, lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is