Original text:
Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media- types@iana.org on Sept 21, 2010.  A second request for all the types <del> was sent on October 31, 2016. </del>  12.3.1. any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del>  Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand.  This allows backwards Encoding considerations: Must be encoded as using RFC7049.  See RFC- AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del>  Interoperability considerations: Applications should ignore any key value pairs that they do not understand.  This allows backwards Encoding considerations: Must be encoded as using W3C.REC-xml- 20081126.  See RFC-AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del>  Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows Encoding considerations: Must be encoded as using W3C.REC-exi- 20140211.  See RFC-AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del>  Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows 13. <del> See sec-privacy.  Further discussion of security properties can be found in sec-iana-media. </del>  14.

Reviewer comments:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM

Revised text:
Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media- types@iana.org on Sept 21, 2010.  A second request for all the types  <ins> was sent on October 31, 2016.  Please change all instances of RFC- AAAA with the RFC number of this document. </ins> 12.3.1. any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable.  <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand.  This allows backwards Encoding considerations: Must be encoded as using RFC7049.  See RFC- AAAA for details.  <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any key value pairs that they do not understand.  This allows backwards Encoding considerations: Must be encoded as using W3C.REC-xml- 20081126.  See RFC-AAAA for details.  <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows Encoding considerations: Must be encoded as using W3C.REC-exi- 20140211.  See RFC-AAAA for details.  <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows 13.  <ins> Sensor data can contain a wide range of information ranging from information that is very public, such as the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  The SenML format does not provide any security and instead relies on the protocol that carries it to provide security.  Applications using SenML need to look at the overall context of how this media type will be used to decide if the security is adequate. See also sec-privacy. </ins> 14.