[payload] Update of security template text in draft-ietf-payload-rtp-howto

[Magnus Westerlund <[e-mail]>]

Payload WG and IESG,

Due to the discussion regarding the security considerations in
draft-ietf-payload-rtp-opus it has been proposed that a small edit is
performed on the security consideration template text that discusses the
role of the security considerations for payload formats.

"How to Write an RTP Payload Format" (draft-ietf-payload-rtp-howto) is
an approved I-D and thus I like to make this consensus call for this
change before acting on it.

Section A.13:

OLD:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
   The rest of the this security consideration discusses the security
   impacting properties of the payload format itself.


NEW:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
   discusses it is not an RTP payload formats responsibility to discuss
   or mandate what solutions are used to meet the basic security goals
   like confidentiality, integrity and source authenticity for RTP in
   general.  This responsibility lays on anyone using RTP in an
   application.  They can find guidance on available security mechanisms
   and important considerations in Options for Securing RTP Sessions
   [RFC7201].  Applications SHOULD use one or more appropriate strong
   security mechanisms.  The rest of the this security consideration
   discusses the security impacting properties of the payload format
   itself.

Change is the new second to last sentence, and updated references.

If no objections are heard in 2 weeks time, by the 25th of April 2015, I
will submit a new version with this change.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------