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

Cool, we have a new version with the proposed text.

Chairs, I think we are ready for WGLC.

Thanks.
-acbegen

On Sat, Sep 16, 2017 at 11:17 AM, Christer Holmberg <
[email protected]> wrote:

> Looks good.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Ali C. Begen [mailto:[email protected]]
> *Sent:* 15 September 2017 23:02
> *To:* Christer Holmberg <[email protected]>
> *Cc:* Eric Rescorla <[email protected]>; Colin Perkins <[email protected]>;
> mmusic WG <[email protected]>; Paul Kyzivat <[email protected]>
>
> *Subject:* Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis
>
>
>
> Hi guys,
>
> Here is the proposed text for 5.12 based on the comments so far:
>
> 5.12.  Encryption Keys ("k=")
>
>       k=<method>
>       k=<method>:<encryption key>
>
> The “k=“ line is obsolete and MUST NOT be used. It is included in this
> document for legacy reasons. One MUST NOT include a "k=" line in an SDP,
> and MUST discard it if it is received in an SDP.
>
>
>
> If we are good with this, I will revise the draft and we will go for WGLC.
>
>
>
> Thanks.
>
> -acbegen
>
>
>
>
>
> On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg <
> [email protected]> wrote:
>
> Hi,
>
>
>
> I support the approach below too.
>
>
>
> However, I think we should have a little more text: saying that k= is
> included for legacy reasons, that one must not include it in SDP, and if
> received must accept and discard it.
>
>
>
> …or something like that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *mmusic <[email protected]> on behalf of Eric Rescorla <
> [email protected]>
> *Date: *Wednesday 13 September 2017 at 01:33
> *To: *Colin Perkins <[email protected]>
> *Cc: *"[email protected]" <[email protected]>, "[email protected]" <
> [email protected]>
> *Subject: *Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis
>
>
>
> This seems like a fine resolution to me.
>
>
>
> On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <[email protected]> wrote:
>
>
> > 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
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>

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