Re: k= and draft-ietf-mmusic-rfc4566bis

> On 12 Sep 2017, at 16:42, Paul Kyzivat <[email protected]> wrote:
> 
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with whatever Colin wants ... but what I was thinking ....
>> k= is still defined by RFC4566 and things that implement RFC4566 still use it. I don't think we have an IANA table for this but if we do, the IANA registry still lists it with the reference for it as RFC4566.
>> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= one way or another. If something that implements RFCAAAA receives a k= line, it gets treated just like any other unknown line and is ignored.
>> There not enough advice on how to use the k= stuff to expect interoperable implementation of any type of security that the IETF would currently consider acceptable to publish as a standard. Anyone who uses k= is very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this in the new RFC and it just adds to the confusion of how to secure RTP.
> 
> One thing: if all mention of k= is removed from the bis, then in the (far) someone who is defining a new line might choose k= for it. (Admittedly this is pretty far fetched.)
> 
> I think a cleaner way to handle this would be to deprecate k= in the bis.

I’d not object if the text in 4566bis was changed to:

================
5.12.  Encryption Keys ("k=")

      k=<method>
      k=<method>:<encryption key>


  The “k=“ line is obsolete and MUST NOT be used.

5.13.  Attributes (“a=“)
…
================

…or something similar. I just don’t think we can remove it entirely.


-- 
Colin Perkins
https://csperkins.org/




_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic