Change:
D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the <del> implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. </del> <ins> implementation.  RID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per- PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 3.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. </ins> If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast"

Discussion:
NAME PTAL
NAME ready for you
And I think the RID one is: URL
NAME PTAL
o An "a=mid" line, as specified in [RFC5888], Section 4. When generating mid values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. Just to note that to my understanding we are having discussion if this should be referencing a more specific generation algorithm. Such a change is likely to affect text on RID also: Section 5.2.1: The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. I would request that we don't use the quite confusing "SHOULD/MUST" and instead write something like: mechanisms that are recommended or mandated to be supported
So proposed plan is we use some of the text Magnus wrote in other comment on this one and bs sepific about no PII or device ID and sugest some ways to solve are random or seuential
Editorial, but someone needs to go find the text.
Note that the resolution to this may be here, in Bundle, or in Security Architecture document; authors are requested to discuss. The same text would likely be needed in any case. Magnus Westerlund has proposed the following text for Bundle: "The identfication-tag when included in the RTP MID SDES item, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag MUST NOT contain any user related information for privacy reasons, nor hardware based identifiers. That as such information could enable tracking of the sending end point. The identification-tag is used to route the media stream to the right application functionality, thus is important that the value received is the one intended by the sender. Malicious modifications can result in that a media stream is wrongly attributed or fails to be played. Thus, verifying integrity and the authenticity of the source are RECOMMENDED to prevent these attacks on the application. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201]."

This clarifies that the MID should have no PII and should not enable tracking of the sending end point. If this advice is followed, the usual requirement to encrypt SDES items in the presence of encrypted RTCP might be waived, if there is consensus that this confidentiality would not serve any purpose commensurate with the difficulty involved. This is permitted by this text in RFC 7941: If the security level is chosen to be different for an SDES item in RTCP and an RTP header extension, it is important to justify the exception and to consider the security properties as the worst in each aspect for the different configurations. This text requires, however, that a justification be provided. It seems best that this justification originate in the RTCWEB working group, no matter where it is eventually documented.
Here's the existing text on generating mid values. We can augment this to simply say to use non-identifying information.